Subject: Re: Quoting (was Re: Content-Type: text/paragraph. An alternative proposal)
From: Harald Tveit Alvestrand <[email-masked]>
To: "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Date: Tue, 24 Feb 1998 11:17:50 +0100

You're getting into the business of sending closures.

Of Taed Nelson's original hypertext vision, closures are the part
that we do NOT find in the current Web; they're *very*, *very* hard
to do seriously when the content is not context independent.

                           Harald A

NOTE: New Email address: [email-masked]
I am working for Maxware (www.maxware.no) as of Dec 1, 1997

Date: Fri, 20 Feb 1998 11:30:12 -0600 (CST)
From: Rick Troth <[email-masked]>
To: [email-masked]
Subject: Re: text/paragraph summary
Sender: [email-masked]

	Aren't we bumping up against the  content -vs- display  problem? 
If so,  are we trying to do what has been wrongly done with HTML?   That is, 
to use a tool designed for content to acomodate presentation?   Let's not. 
 
	The single worst thing about the web is that marketers 
and marketeers  (and the two are different)  use HTML for layout. 
(This is not to ignore mis-matched capabilities between various 
browser/server pairs,  which is also a serious problem.) 
 
	I don't think the situation is going to be corrected 
until the MUA developers understand the difference between content 
and presentation strongly enough to force a clue into the grey cells 
of the users.   We can't retrain the millions of users on the Internet, 
but we *can* put clarification in the RFCs which some MUA developers 
will hopefully read.   Say it early;  say it often. 
 
	Maybe the new text subtype should be  "/layout".   Naahh. 
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Fri, 20 Feb 1998 08:41:14 -0500 (EST)
From: Nathaniel Borenstein <[email-masked]>
To: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
CC: Steve Dorner <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

Excerpts from bulk.interesting.mildly: 19-Feb-98 Re: overdefining
text/plain? Ned [email-masked] (3278*)

> I have a non-procedural problem with the parameter approach, myself. I see
> this as broadening the definition of text/plain to include material which is
> not presently legal. This weakens the definition and makes it harder to deal
> effectively with incompliant products.

OK, Ned, you've convinced me that the subtype approach is preferable to
the parameter approach.  -- Nathaniel
--------
In the long run men hit only what they aim at.  Therefore, though they
should fail immediately, they had better aim at something high.  -- Thoreau

Nathaniel Borenstein <[email-masked]>          |  FAQ & PGP key:
Chief Scientist, First Virtual Holdings    |  [email-masked]

Date: Thu, 19 Feb 1998 21:43:43 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: text/paragraph summary
To: Steve Dorner <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Except for my fear of mailers not liking text/whatever, I'm very tempted to
> pretend that TEXT/plain wasn't ever defined, at least for sending purposes.
> I see no point in prohibiting recipient-imposed wrapping.  I can't see any
> downside at all to sending even short lines in text/paragraph.  This is
> another thing that makes me think 2046 was wrong to add the "no wrap"
> restriction.

Ahem. First of all, RFC 2046 doesn't have a "no wrap" restriction. What it 
does is state that text/plain must be formatted so that wrapping is not
required for proper display. The CRLFs that are there are meaningful and, if
possible, should be honored to get the best possible result.

But nowhere is display wrapping forbidden, and indeed, it is obvious that
wrapping may be necessary on, say, very narrow displays like PDAs.

Second, none of this is new to RFC 2046. The same requirements were in
RFC 1341 and RFC 1521, but unfortunately there were problems with the phrasing
that resulted in some people misinterpreting things. The only thing that
was changed was the phrasing; the requirements in this area are the same
as what was agreed to by the Working Group. Indeed, at the time I and several
others would have regarded a definition of text/plain that allowed for
text/paragraph behavior as a showstapper.

				Ned

Date: Thu, 19 Feb 1998 17:18:35 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Quoting (was Re: Content-Type: text/paragraph. An alternative proposal)
To: [email-masked]
Sender: [email-masked]

I garbled this the first time; here it is again...

> I suppose it may be too complex for people to worry about now, but it always
> struck me that in the secure mail / MIME world, what you needed was some sort
> of "window" MIME type.  If you want to quote something in such a way that the
> recipient can veryify the signature on what you are quoting, then you need to
> forward the entire signed object and have some way via a "window" MIME object
> to reference it and say what part you are quoting. 

We actually have this already, more or less -- we have ways of including
material pointed to by a URL in a message and URLs that can be used to refer to
a particular message part.

Specifically, we have the URL access-type for message/external-body. We also
have the ability to incorporate material from a URL directly into text/html
parts. And we have URLs that let you reference either a message (mid) or a part
of a message (cid).

Now,I don't know if the mid or cid URLs forms support any sort of fragment
reference. But it would be easy to add this concept (for text at least) if 
they do not.

Implementation of all this is another matter, of course. But the necessary
infrastructure is for the most part already in place.

				Ned

To: Jacob Palme <[email-masked]>
cc: Ned Freed <[email-masked]>, [email-masked]
Subject: Re: Quoting (was Re: Content-Type: text/paragraph. An alternative proposal) 
Date: Thu, 19 Feb 1998 16:28:10 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]

>The way I understand the general URL format specification in
>draft-fielding-url-syntax-07.txt, any URL can have a fragment added to it.
>Thus, the specification of a specific URL type, like the specification
>of the cid and mid URL type in draft-ietf-mhtml-cid-v2-00.txt does not
>need to say anything about fragments.

Yes, the presence or absence of a fragment is a property of the reference
and not the URL scheme.  One thing that is useful for a URL scheme spec
to say is whether or not it can be used as a hypertext (retrieval style)
reference, since that determines whether or not a fragment would be
meaningful.

....Roy

Date: Thu, 19 Feb 1998 22:04:00 +0100
To: Ned Freed <[email-masked]>, Roy Fielding <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: Quoting (was Re: Content-Type: text/paragraph. An alternative proposal)
Cc: [email-masked]
Sender: [email-masked]

At 09.48 -0800 98-02-19, Ned Freed wrote:
>Now,I don't know if the mid or cid URLs forms support any sort of fragment
>reference. But it would be easy to add this concept (for text at least) if
>they do not.

The way I understand the general URL format specification in
draft-fielding-url-syntax-07.txt, any URL can have a fragment added to it.
Thus, the specification of a specific URL type, like the specification
of the cid and mid URL type in draft-ietf-mhtml-cid-v2-00.txt does not
need to say anything about fragments.

Can someone tell me if this is true or not? I am copying this message
to Roy Fielding, the main author of draft-fielding-url-syntax-07.txt,
so that he can explain this.

If Roy's answer is that every specification of a special cid or mid
URL type needs to say explicitly that they can have fragments, then
I think we should change draft-ietf-mhtml-cid-v2-00.txt. I will
in that case ensure that this is done, since the responsibility
for draft-ietf-mhtml-cid-v2-00.txt is with the mhtml group. I will
either change it myself, or ask the author of
draft-ietf-mhtml-cid-v2-00.txt, Ed Levinson, to do it.

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Fri, 20 Feb 1998 01:05:11 +0100
To: [email-masked], Steve Dorner <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Cc: [email-masked]
Sender: [email-masked]

At 18:10 18.02.98 -0500, [email-masked] wrote:
>On Wed, 18 Feb 1998 14:23:59 CST, you said:
>> Actually, you quoted the above with ">SPACE", not '>'.  Chris's proposed
>> quoting language does not say anything about whitespace, and would fail on
>> text using the quoting you just did.  I quoted you with just '>', so I'm
>> Chris's best buddy.  :-)
>
>Exactly. That was my point. ;) 
>From practical experience, I know that a lot of people will see this
(the previous) line prefixed with exactly the character commonly used for
quoting.

Now try to decide how to write an UA that deals properly with that
situation :-)

Quoting in text/plain is a rather poor convention that won't be perfect in
any nearby millenium; heuristics are probably no worse for text/paragraph
than for text/plain.

I suggest we don't try for perfection on this issue, and get
text/paragraph registered.
(hmmm.....that's the IETF subtree, where we keep "recommended" types.
Is there a reason to define the text/ietf.distasteful.* subtree? :-)

                Harald A

(whose point may be obscured by a good UA at the sending side....)

NOTE: New Email address: [email-masked]
I am working for Maxware (www.maxware.no) as of Dec 1, 1997

Date: Thu, 19 Feb 1998 14:18:56 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: text/paragraph summary
Sender: [email-masked]

>> > (2) There might, at some time in the future, be a wish to use this
>> >     subtype to other primary types than text/plain.
>
>widetext/paragraph

widetext/plain; wrap=whatever

I don't see there's much difference between a subtype and a parameter in
this respect.

Beside the issue of MUA's that don't deal with text/whatever, what about
non-traditional MUA's like fax gateways, pager gateways, etc, etc?  These
may tend to be quite a bit more "suspicious" about text/whatever, and I'm
pessimistic about how easy it will be to get these things fixed.

>In fact it might simplify things to never define widetext/plain -- thus

Except for my fear of mailers not liking text/whatever, I'm very tempted to
pretend that TEXT/plain wasn't ever defined, at least for sending purposes.
I see no point in prohibiting recipient-imposed wrapping.  I can't see any
downside at all to sending even short lines in text/paragraph.  This is
another thing that makes me think 2046 was wrong to add the "no wrap"
restriction.

Date: Thu, 19 Feb 1998 11:07:21 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: text/paragraph summary
To: [email-masked]
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 19 Feb 1998 [email-masked] wrote:
> > (2) There might, at some time in the future, be a wish to use this
> >     subtype to other primary types than text/plain.
> 
> audio/paragraph?  video/paragraph?  I admit that either I need more
> caffeine, or I'm being more than usually dense here?

widetext/paragraph

In fact it might simplify things to never define widetext/plain -- thus 
pushing widetext wrapping to the client in all cases.  Of course, that
toplevel type is still a few years in the future.

		- Chris

To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Subject: Re: text/paragraph summary 
From: [email-masked]
Date: Thu, 19 Feb 1998 13:19:28 -0500
Sender: [email-masked]

--==_Exmh_-1107042174P
Content-Type: text/plain; charset=us-ascii

On Thu, 19 Feb 1998 18:07:45 +0100, you said:
> A text subtype has two advantages:
> (1) Recipients which do not understand the subtype may process the
>     message as text/plain.

Very true.

> (2) There might, at some time in the future, be a wish to use this
>     subtype to other primary types than text/plain.

audio/paragraph?  video/paragraph?  I admit that either I need more
caffeine, or I'm being more than usually dense here?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-1107042174P
Content-Type: application/pgp-signature

--==_Exmh_-1107042174P--

Date: Thu, 19 Feb 1998 09:48:41 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Quoting (was Re: Content-Type: text/paragraph. An alternative proposal)
To: "Donald E. Eastlake 3rd" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I suppose it may be too complex for people to worry about now, but it always
> struck me that in the secure mail / MIME world, what you needed was some sort
> of "window" MIME type.  If you want to quote something in such a way that the
> recipient can veryify the signature on what you are quoting, then you need to
> forward the entire signed object and have some way via a "window" MIME object
> to reference it and say what part you are quoting. 

We actually have this already, more or less -- we have ways of including
material pointed to by a URL in a message and URLs that can be used to refer to
a particular message part.

Specifically, we have the URL access-type for message/external-body. We also
have the ability to incorporate material from a URL directly into text/html
parts. And we have URLs that let you reference either a message (mid) or a part
of a message (cid).

Now,I don't know if the mid or cid URLs forms support any sort of fragment
reference. But it would be easy to add this concept (for text at least) if 
they do not.

Implementation of all this is another matter, of course. But the necessary
infrastructure is for the most part already in place.

				Ned

Date: Thu, 19 Feb 1998 18:07:45 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: text/paragraph summary
Sender: [email-masked]

>There is an open issue of whether to disabiguate by text subtype or by a
>content-type parameter.  If you not yet argued your preference, your
>input would be welcome.

A text subtype has two advantages:
(1) Recipients which do not understand the subtype may process the
    message as text/plain.
(2) There might, at some time in the future, be a wish to use this
    subtype to other primary types than text/plain.

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Thu, 19 Feb 1998 09:27:47 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
To: Nathaniel Borenstein <[email-masked]>
Cc: Steve Dorner <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

> > > Perhaps it would be better to put such hints in a parameter instead.
> > > Define a "wrap" parameter, with values of "please" and "nothankyou" or
> > > something.  This would have the advantage of not running afoul of mailers
> > > that choke on text/anything-they-dont-know-about.

> > Such mailers violate RFC 2049, so I'm inclined to ignore them.  Nor am I
> > sure there's an option to add a parameter to a standards track media type
> > without resetting it to proposed.

As I said to Chris privately yesterday, I agree with this. I think a new
document could be written that extends the definition of text/plain with
an added parameter, and that document would have little trouble moving
along the standards track.

> I really don't think there's a problem with defining a new parameter, as
> long as the default is defined in such a way that the absence of such a
> parameter yields the current text/plain semantics.

I have a non-procedural problem with the parameter approach, myself. I see
this as broadening the definition of text/plain to include material which is
not presently legal. This weakens the definition and makes it harder to deal
effectively with incompliant products. We actually have a pretty good track
record of getting the more popular incompliant products to stop misusing
text/plain. The products of a certain company headquartered in Redmond,
Washington are a case in point. I know for a fact that the specificity of the
definition of text/plain was the overriding factor in getting them to change.
And while having a parameter would have avoided the need for them to change, I
worry about what will happen with a weakened definition of text/plain the next
time we run into some form of incompliancy.

Now, this may sound like I don't think we should be doing text/paragraph, since
after all, if we can get people to switch to doing text/plain properly, why
bother? But the problem isn't that we haven't been able to get things changed
-- we have -- it is instead that we have had to go to a lot of trouble to get
this to happen, and it has been a tough sell because of the lack of available
alternatives. Text/paragraph fixes this, since it is much easier to tell
someone to change a label than it is to tell them to write a lot of new code.

> I see some appeal in adding parameters to text/plain, on the assumption
> that they may all be ignored by many mail readers.  But I also know that
> many systems can be customized/extended by subtypes, but not by
> parameters.  (Metamail, for the record, can work either way.)  So I
> don't see any truly compelling argument one way or the other.....

The inability to switch on parameters is also a problem, of course. But I see
this as quite different from the problem we have with broken agents that are
unwilling to handle unrecognized subtypes of text as text/plain. In one case we
penalize people for not doing something we never told them we had to do -- we
never said in so many words that parameter-based dispatching was a requirement.
But in the other case we did say quite explicitly what had to be done. Given
the choice between causing problems for conformant inplementations and causing
problems for nonconformant implementations, I  think the right choice is
obvious.

				Ned

Date: Thu, 19 Feb 1998 12:00:14 -0500 (EST)
From: "Donald E. Eastlake 3rd" <[email-masked]>
To: [email-masked]
Subject: Quoting (was Re: Content-Type: text/paragraph. An alternative proposal)
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

--==_Exmh_-1527006096P
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <[email-masked]>

Note that the mail below which I am responding to has a signature.  How easy
is it to check the signature with the quoting convention used?  Note that any
attempt at partial quoting break signatures. 

Then there is encryption.  In general, you may need to decrypt and re-encrypt
any encrypted mail you are quoting.  At least, most likely, if it arrived
encrypted, you wouldn't want to sent out a quote from it in plain text by
default... 

I suppose it may be too complex for people to worry about now, but it always
struck me that in the secure mail / MIME world, what you needed was some sort
of "window" MIME type.  If you want to quote something in such a way that the
recipient can veryify the signature on what you are quoting, then you need to
forward the entire signed object and have some way via a "window" MIME object
to reference it and say what part you are quoting.  Clever user interfaces to
show this and allow the user to grow the window and see more of the
authenticated original are left as an exercies for the reader... 

But, as I say, I suppose this is too complex for the present...

Donald

On Wed, 18 Feb 1998 [email-masked] wrote:

> Date: Wed, 18 Feb 1998 18:10:18 -0500
> From: [email-masked]
> To: Steve Dorner <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Content-Type: text/paragraph. An alternative proposal 
> 
> On Wed, 18 Feb 1998 14:23:59 CST, you said:
> > Actually, you quoted the above with ">SPACE", not '>'.  Chris's proposed
> > quoting language does not say anything about whitespace, and would fail on
> > text using the quoting you just did.  I quoted you with just '>', so I'm
> > Chris's best buddy.  :-)
> 
> Exactly. That was my point. ;) 
> 
> -- 
> 				Valdis Kletnieks
> 				Computer Systems Senior Engineer
> 				Virginia Tech
> 
> 

=====================================================================
Donald E. Eastlake 3rd     +1 978-287-4877(tel)     [email-masked]
   318 Acton Street        +1 978-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.privacy.org/ipc

--==_Exmh_-1527006096P--

Date: Thu, 19 Feb 1998 10:44:28 -0500 (EST)
From: Nathaniel Borenstein <[email-masked]>
To: Steve Dorner <[email-masked]>, Chris Newman <[email-masked]>
Subject: Re: overdefining text/plain?
CC: [email-masked]
Sender: [email-masked]

Excerpts from bulk.interesting.mildly: 18-Feb-98 Re: overdefining
text/plain? Chris [email-masked] (2358*)

> > Perhaps it would be better to put such hints in a parameter instead.
> > Define a "wrap" parameter, with values of "please" and "nothankyou" or
> > something.  This would have the advantage of not running afoul of mailers
> > that choke on text/anything-they-dont-know-about.

> Such mailers violate RFC 2049, so I'm inclined to ignore them.  Nor am I
> sure there's an option to add a parameter to a standards track media type
> without resetting it to proposed. 

I really don't think there's a problem with defining a new parameter, as
long as the default is defined in such a way that the absence of such a
parameter yields the current text/plain semantics.

I see some appeal in adding parameters to text/plain, on the assumption
that they may all be ignored by many mail readers.  But I also know that
many systems can be customized/extended by subtypes, but not by
parameters.  (Metamail, for the record, can work either way.)  So I
don't see any truly compelling argument one way or the other.....
--------
In the long run men hit only what they aim at.  Therefore, though they
should fail immediately, they had better aim at something high.  -- Thoreau

Nathaniel Borenstein <[email-masked]>          |  FAQ & PGP key:
Chief Scientist, First Virtual Holdings    |  [email-masked]

Date: Wed, 18 Feb 1998 19:16:47 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: text/paragraph summary
To: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

Let's see where we are:

There seems to be a rough concensus that text/plain is currently
overloaded and something to disambiguate paragraph-formatted text from
line-formatted text would be useful.  Any objections?

There seems to be some feeling that it is often preferable to have the
recipient do line wrapping (esp. for narrow display devices like PDAs and
cell-phones).  Anyone wish to argue the opposite?

There seems to be a lot of sentiment that the quoting convention needs to
be more precise for paragraph-oriented text.  Objections?

There is an open issue of whether to disabiguate by text subtype or by a
content-type parameter.  If you not yet argued your preference, your
input would be welcome.

		- Chris

Date: Thu, 19 Feb 1998 03:51:22 +0100
To: Dan Wing <[email-masked]>, [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

At 11.59 -0800 98-02-18, Dan Wing wrote:
>I don't think deprecating text/paragraph is a good idea.  The reason
>text/plain is being abused is because it is useful to send entire
>paragraphs in one line and let the receipient's MUA word wrap.  Today
>it is useful because of wide displays, and tomorrow it'll be useful
>for narrow displays (on PDAs), as was pointed out.

I agree.

(Would it not be nice, if e-mail allowed me to say "I agree" without
having to disturb everyone by sending them a separate message. My
"agreement" could instead be automatically collated with other
agreements and disagreements and shown statistically to users.
But the way e-mail works today, the only way you have to say that
you agree is to send a separate message saying this!)

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

To: Steve Dorner <[email-masked]>
Cc: [email-masked]
Subject: Re: Content-Type: text/paragraph. An alternative proposal 
From: [email-masked]
Date: Wed, 18 Feb 1998 18:10:18 -0500
Sender: [email-masked]

--==_Exmh_-1527006096P
Content-Type: text/plain; charset=us-ascii

On Wed, 18 Feb 1998 14:23:59 CST, you said:
> Actually, you quoted the above with ">SPACE", not '>'.  Chris's proposed
> quoting language does not say anything about whitespace, and would fail on
> text using the quoting you just did.  I quoted you with just '>', so I'm
> Chris's best buddy.  :-)

Exactly. That was my point. ;) 

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-1527006096P
Content-Type: application/pgp-signature

--==_Exmh_-1527006096P--

Date: Wed, 18 Feb 1998 14:23:59 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

At 2:00 PM -0600 2/18/98, [email-masked] wrote:
>On Wed, 18 Feb 1998 11:41:48 CST, Rick Troth said:
>> On Wed, 18 Feb 1998, Ian Bell wrote:
>> > The conclusion must be that using _any_ quote character when replying in
>> > text/paragraph may cause damage to the ensuing conversation thread. The
>> > problem does not lie in MUAs but in text/paragraph itself.
>> 	This connection I do NOT see.
>
>The problem is that although (for example), the above got quoted using
>the pseudo-standard '>' character, there's no good way to flag what
>*was* actually used.

Actually, you quoted the above with ">SPACE", not '>'.  Chris's proposed
quoting language does not say anything about whitespace, and would fail on
text using the quoting you just did.  I quoted you with just '>', so I'm
Chris's best buddy.  :-)

Date: Wed, 18 Feb 1998 14:14:01 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: overdefining text/plain?
Sender: [email-masked]

At 12:24 PM -0600 2/18/98, Chris Newman wrote:
>It has never been legal to generate paragraph-based text
>and label it as text/plain (unless all paragraphs are less than 80-cols).

There is nowhere a mention of an 80 column restriction for text/plain, and
if there were it would be meaningless anyway, because of narrow devices.

A no-wrap restriction is not workable for the basic text type and I think
it should be given up.  The "bad" example in your RFC is cute, but it's a
lot more legible than:

	A no-wrap restriction is not workable for the basic
	it should be given up.  The example in your RFC is r
	lot more legible than:

which is what a no-wrap rule is asking for.

>>This would have the advantage of not running afoul of mailers
>> that choke on text/anything-they-dont-know-about.
>
>Such mailers violate RFC 2049, so I'm inclined to ignore them.

One of those mailers used to be AOL.  Ignoring AOL is impractical.  Now, it
may be that AOL has fixed their problem, but I'm not in general comfortable
with the risk.  If I start generating text/paragraph and some large user
base botches it, users complain to me, and are relatively unimpressed when
I quote RFC's to them.  (I'm currently having this problem with 8bitmime
and MSN...)

>Nor am I
>sure there's an option to add a parameter to a standards track media type
>without resetting it to proposed.

Argument from ietf process doesn't tickly my ivories.  Now, if we all
believe that all the major players are up to snuff in this regard, and we
think they'll all continue to be, fine.  It scares ME, but maybe I'm just
chicken.

To: Rick Troth <[email-masked]>
Cc: [email-masked]
Subject: Re: Content-Type: text/paragraph. An alternative proposal 
From: [email-masked]
Date: Wed, 18 Feb 1998 15:00:43 -0500
Sender: [email-masked]

--==_Exmh_-2087803234P
Content-Type: text/plain; charset=us-ascii

On Wed, 18 Feb 1998 11:41:48 CST, Rick Troth said:
> On Wed, 18 Feb 1998, Ian Bell wrote:
> > The conclusion must be that using _any_ quote character when replying in
> > text/paragraph may cause damage to the ensuing conversation thread. The
> > problem does not lie in MUAs but in text/paragraph itself.
> 	This connection I do NOT see. 

The problem is that although (for example), the above got quoted using
the pseudo-standard '>' character, there's no good way to flag what
*was* actually used.  For instance, there's MUA's out there that will
generate something based on the quoted user's name - so one of the
lines above *could* have started out like this:

Rick: Ian> problem does not lie.....

Mix this with the commonly used tactic of inserting your commentary
between the displayed lines of a paragraph, and you're headed for
a near-guaranteed mess.  Especially when considering that a large
part of the user base has MUAs that will punt text/paragraph back
to text/plain.... 

For the curious, almost the exact same problem in another guise
crops up with the question of replying-with-commentary to a
multipart/signed.  This mail is PGP-signed - but if you reply to it
and add commentary, it invalidates my signature on the text.  So
although I can prove what-I-said for *THIS* note, I can't pass that
on to OTHER follow-up notes where I could be edited/misquoted/etc...

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-2087803234P
Content-Type: application/pgp-signature

--==_Exmh_-2087803234P--

Date: Wed, 18 Feb 1998 11:59:34 -0800
From: Dan Wing <[email-masked]>
To: [email-masked]
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

Chris Newman <[email-masked]> wrote:

>Sigh.  I was hoping I didn't have to deal with this head-on as it's an MUA 
>convention and not part of the media type.  How about adding the
>following section:
>
>---
>4.1. Requirements for Use of text/paragraph in Internet Mail
>
>Mail User Agents SHOULD generate text/plain instead of text/paragraph in
>Internet mail.  

I don't think deprecating text/paragraph is a good idea.  The reason
text/plain is being abused is because it is useful to send entire
paragraphs in one line and let the receipient's MUA word wrap.  Today
it is useful because of wide displays, and tomorrow it'll be useful
for narrow displays (on PDAs), as was pointed out.

If text/paragraph exists and is deployed, I think it would be a Good
Thing -- there's no need to suggest text/plain is preferred.  Obviously
non-MIME-aware UAs and gateways would prefer non-abused text/plain, but 
non-abused text/plain is becoming scarce as many mailers generate
"abused" text/plain. 

>Gateways from systems which use text/paragraph to
>Internet mail SHOULD convert to text/plain and MUST NOT label 
>paragraph-based text as text/plain.
[...]

I think requiring paragraph-based text to be labeled as text/paragraph 
is sufficient.  Recommending that gateways emit text/plain is 
overly restrictive.  Text/paragraph has distinct advantages over
(non-abused) text/plain.

My recommendation is that text/paragraph SHOULD be generated if the MUA
or gateway wants to generate it.  I don't think re-stating the 
proper use of text/plain in the text/paragraph Internet Draft will
change existing use of text/plain.  It certainly won't change the
reason text/plain is being abused.

-Dan Wing

Date: Wed, 18 Feb 1998 10:24:52 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: overdefining text/plain?
To: Steve Dorner <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Wed, 18 Feb 1998, Steve Dorner wrote:
> 1. I think that more and more "nonconformant" uses of text/plain will be
> discovered, and that we're going to wind up with a plethora of text/
> subtypes, each with narrow definitions and little hope of widespread
> implementation.  text/plain itself will be illegal for practically anything.

It has never been legal to use CRLF for anything other than "line break"
in text/plain.  The MIME standard is quite clear on that point.  It is
also clear that text/plain is intended to be displayed without formatting
or processing.  It has never been legal to generate paragraph-based text
and label it as text/plain (unless all paragraphs are less than 80-cols).

I don't think we can change the definition of text/plain at this point,
since changing it would require a reset of MIME to proposed standard.  We
can clarify it and provide alternatives for misuse of the media type.

> denominator.  For better or worse, I think we'll soon be seeing a much
> greater influx of 40 or 30 or even 20 character "terminals" in the near
> future as more and more portable devices get on the net.  Your "MUST" allow
> an option not to wrap is very likely to be ignored by such systems.

This is a very good point.  I will take it into account in the next
revision.

> I would prefer that the honus for text/plain remain on the receiver; that
> the receiving MUA do "something reasonable" with it, without making too
> many assumptions. I don't want to get into a situation where it's perfectly
> acceptable for a mailer to dump a piece of text/plain on the floor because
> the sender didn't put two spaces after every period or whatever.

Any mailer which dropped any text/plain no matter how illegal will get
dropped as well.  It's a practical requirement to offer a line-wrap option
for text/plain even though it was never intended to need line-wrapping.

> Perhaps it would be better to put such hints in a parameter instead.
> Define a "wrap" parameter, with values of "please" and "nothankyou" or
> something.  This would have the advantage of not running afoul of mailers
> that choke on text/anything-they-dont-know-about.

Such mailers violate RFC 2049, so I'm inclined to ignore them.  Nor am I
sure there's an option to add a parameter to a standards track media type
without resetting it to proposed. 

		- Chris

Date: Wed, 18 Feb 1998 10:06:14 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Wed, 18 Feb 1998, Ian Bell wrote:
> I think the draft must be changed in this area: perhaps to deprecate the
> use of quote characters within text/paragraph, or maybe to say that MUAs
> SHOULD downgrade to text/plain before quoting. Maybe even to deprecate
> text/paragraph itself and make it clear that the RFC (to be) only exists
> to deal with the current practice of misusing qp and text/plain.

Sigh.  I was hoping I didn't have to deal with this head-on as it's an MUA 
convention and not part of the media type.  How about adding the
following section:

---
4.1. Requirements for Use of text/paragraph in Internet Mail

Mail User Agents SHOULD generate text/plain instead of text/paragraph in
Internet mail.  Gateways from systems which use text/paragraph to
Internet mail SHOULD convert to text/plain and MUST NOT label 
paragraph-based text as text/plain.

A common convention in Internet messages is to indicate quoted text by
preceeding each line with a quote character of the user's choice. 
However, because it is necessary to line-wrap text/paragraph on display a
more precise convention is necessary in text/paragraph.  When quoted text
is included in text/paragraph, the paragraph is preceeded with a ">". 
When displaying text/paragraph or converting it to text/plain, agents
supporting this convention will copy all ">"s at the beginning of a
paragraph to the beginning of each line-wrapped line of that paragraph. 
---

		- Chris

Date: Wed, 18 Feb 1998 11:34:14 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: overdefining text/plain?
Sender: [email-masked]

I'm not convinced that the semantics of text/plain should be so precise as
to indicate "no wrapping permitted" (yes, I agree that Chris's
text/paragraph draft doesn't go that far).  Or that it's even wise to
suggest that MUA's MUST offer certain options when dealing with it.

I think this for two reasons:

1. I think that more and more "nonconformant" uses of text/plain will be
discovered, and that we're going to wind up with a plethora of text/
subtypes, each with narrow definitions and little hope of widespread
implementation.  text/plain itself will be illegal for practically anything.

2. For many years almost all client systems have been getting MORE capable,
and the "old standard" of an 80-column terminal has been the least common
denominator.  For better or worse, I think we'll soon be seeing a much
greater influx of 40 or 30 or even 20 character "terminals" in the near
future as more and more portable devices get on the net.  Your "MUST" allow
an option not to wrap is very likely to be ignored by such systems.

I would prefer that the honus for text/plain remain on the receiver; that
the receiving MUA do "something reasonable" with it, without making too
many assumptions. I don't want to get into a situation where it's perfectly
acceptable for a mailer to dump a piece of text/plain on the floor because
the sender didn't put two spaces after every period or whatever.

I've no objection to also defining text/paragraph, for an explicit hint
that wrapping is desired.  And no objection either to text/70s, as an
explicit hint that wrapping is unwelcome.

Perhaps it would be better to put such hints in a parameter instead.
Define a "wrap" parameter, with values of "please" and "nothankyou" or
something.  This would have the advantage of not running afoul of mailers
that choke on text/anything-they-dont-know-about.

Date: Wed, 18 Feb 1998 11:41:48 -0600 (CST)
From: Rick Troth <[email-masked]>
To: Ian Bell <[email-masked]>
cc: [email-masked]
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

On Wed, 18 Feb 1998, Ian Bell wrote:

	I think you're missing the advantage of the "paragraph" label. 
 
> 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.
 
	Won't happen.   Actually,  it COULD happen,  but the burden 
is placed squarely on the back of the user agent to deal with this. 
We can then fairly point the finger at the clear offender. 
 
> which may get displayed as
> 
>         >A message with ...
>         >... a very long line.
> or 
>         >A message with ...
>         ... a very long line.
 
	In a world where text/paragraph is a properly defined standard, 
the latter is wrong.   Period.   If the user doesn't care,  then do we? 
I certainly care,  and would complain loudly to my MUA vendor. 
 
> depending on whether the MUA decides to do anything at all about quoted
> material (current draft says MUAs "MAY wish to consider" quoting
> conventions).
 
	Excellent point.   Stronger wording is in order there. 
 
> The user, if presented with the second version, will say that the message
> display is broken because text is being mis-attributed. The retort here
> could simply be that the MUA displaying the message is broken because it
> is displaying the message sub-optimally. Bad, but the finger of blame gets
> pointed at that MUA.
 
	The light goes on for me.   (It takes a while.) 
 
	You're worried about mis-quotes being sent,  not so much 
mis-quotes displayed.   Good point.   I don't see a way to reliably 
coerce the replying MUA into compliance.   Does that make the 
standard bad?   No. 
 
> In order to display this message properly to the user (ie to give the
> correct impression of who said what), the receiving MUA is going to have
> to successfully parse these forms. Any failure in display can't really be
> put at the door of the MUA as there is no RFC that governs quoting
> conventions - the failure comes from the media-type itself. At this point,
> though, the message itself won't be broken since examining the source
> line-breaks will determine correctly the authors involved.
 
	The closest thing I've seen is HTML  (which is annoying 
when sent through mail,  as some will agree).   I can imagine 
nesting of blocks of quoted material. 
 
> The conclusion must be that using _any_ quote character when replying in
> text/paragraph may cause damage to the ensuing conversation thread. The
> problem does not lie in MUAs but in text/paragraph itself.
 
	This connection I do NOT see. 
 
> -- 
> Ian Bell                                           T U R N P I K E  Ltd
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Wed, 18 Feb 1998 18:17:21 +0100
To: Ian Bell <[email-masked]>, [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

At 14.37 +0000 98-02-18, Ian Bell wrote:
>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.

The best mailer I have seen for handling this specific problem is Pine.
If Pine gets as input a message with

>A very long line one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen, etc.

this line will automatically get displayed to its reader as

>A very long line one two three four five six seven eight nine ten
>eleven twelve thirteen fourteen fifteen sixteen seventeen, etc.

If the writer of a reply containing the above text edits the text,
and changes it to, for example:

>five six seven eight nine ten
>eleven twelve thirteen fourteen fifteen sixteen seventeen, etc.

and if the writer of the reply applies the justify command in Pine,
the result will be

>five six seven eight nine ten eleven twelve thirteen fourteen
>fifteen sixteen seventeen, etc.

and not, for example,

>five six seven eight nine ten >eleven twelve thirteen fourteen
fifteen sixteen seventeen, etc.

as one could expect of more simpleminded editors.

All my praise and admiration to the developers of Pine!

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Wed, 18 Feb 1998 9:08:23 -0800
From: Dan Wing <[email-masked]>
To: [email-masked]
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

>I think the draft must be changed in this area: perhaps to deprecate the
>use of quote characters within text/paragraph, or maybe to say that MUAs
>SHOULD downgrade to text/plain before quoting. 

That would work for all the quoted material, I suppose, but we would
be back to the same problem we have today with MUAs that use QP for
the long lines of the original (non-quoted) replies.

I think we can still have quoted text with text/paragraph.  Only the
beginning of a paragraph will have the quoting character which is 
replicated for each (wrapped) line of the paragraph.  Perhaps 
text/paragraph could indicate that ">", ":", (and maybe a few
others?) should be handled similarly as quoting characters and
should be replicated on every line?

(I was also thinking that perhaps including ';quote-string=">"' after
the content-type might allow different quote strings, but it is
possible for multiply-quoted text to be taken apart for quoting
individual authors, leaving their funky quote characters at the
beginning of lines.  Maybe a list of quote strings from each reply,
sortof like References: headers?  Then any line beginning with any
of the quote strings could be handled like ">" by the line wrapping 
code in the MUA that supports text/paragraph?)

As for splitting a paragraph which has been wrapped, this can be
acheived by the MUA having the new paragraph start with the same quote
character.  Netscape 4's mailer already seems to do this (if you have
checked "by default, send HTML messages" in Edit | Preferences |
Mail & Groups | Messages), but the reply text/plain, of course.

For example, if you receive: 

  Content-Type: text/paragraph

  >Hi.  I was hoping you were interested in the fantastic =
  opportunity to make money fast.  Yes, unlike all the other =
  scams on the net, this one is real.  Why?  Because you can =
  trust me.  Really!  <wink>.

You might want to quote the first sentence.  The MUA would have to
generate another quote character for the paragraph you broke in two
pieces.  It would send back something like this:

  Content-Type: text/paragraph

  >Hi.  I was hoping you were interested in the fantastic =
  opportunity to make money fast.

  Um, no, I don't think so.  But thanks very much.  I don't =
  receive enough of these offers every day.

  >Yes, unlike all the other =
  scams on the net, this one is real.  Why?  Because you can =
  trust me.  Really!  <wink>.

then, that recipient makes another reply:

  Content-Type: text/paragraph

  >>Hi.  I was hoping you were interested in the fantastic =
  opportunity to make money fast.

  >Um, no, I don't think so.  But thanks very much.  I don't =
  receive enough of these offers every day.

  What do you mean?  I spent lots of money on this mailing =
  list, and found a mail relay I could use (you don't know how =
  difficult that is now!).  How can you not be interested?

  >>Yes, unlike all the other =
  scams on the net, this one is real.  Why?  Because you can =
  trust me.  Really!  <wink>.

>Maybe even to deprecate
>text/paragraph itself and make it clear that the RFC (to be) only exists
>to deal with the current practice of misusing qp and text/plain.

I don't think we're going to eliminate the misuse of text/plain -- 
variable-width characters, and people that full-screen their mailers 
on huge monitors cause people to want to see really long lines and
use up all that real estate.

-Dan Wing

Date: Wed, 18 Feb 1998 14:37:09 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

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.
or 
        >A message with ...
        ... a very long line.
         
depending on whether the MUA decides to do anything at all about quoted
material (current draft says MUAs "MAY wish to consider" quoting
conventions).

The user, if presented with the second version, will say that the message
display is broken because text is being mis-attributed. The retort here
could simply be that the MUA displaying the message is broken because it
is displaying the message sub-optimally. Bad, but the finger of blame gets
pointed at that MUA.

If that paragraph gets requoted, it may get requoted as (using quoting
methods used in other messages in this thread):

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

or, using other quote characters (thankfully seen mainly on UseNet)

        : >A message with ... ... a very long line.
or
        = >A message with ... ... a very long line.

or any number of variations

In order to display this message properly to the user (ie to give the
correct impression of who said what), the receiving MUA is going to have
to successfully parse these forms. Any failure in display can't really be
put at the door of the MUA as there is no RFC that governs quoting
conventions - the failure comes from the media-type itself. At this point,
though, the message itself won't be broken since examining the source
line-breaks will determine correctly the authors involved.

However, as soon as the user splits paragraphs in order to quote at the
most relevant point, the display problem becomes a problem with the reply
source itself. The final recipient will then be unable to deduce the
correct authorship of the text.

The conclusion must be that using _any_ quote character when replying in
text/paragraph may cause damage to the ensuing conversation thread. The
problem does not lie in MUAs but in text/paragraph itself.

I think the draft must be changed in this area: perhaps to deprecate the
use of quote characters within text/paragraph, or maybe to say that MUAs
SHOULD downgrade to text/plain before quoting. Maybe even to deprecate
text/paragraph itself and make it clear that the RFC (to be) only exists
to deal with the current practice of misusing qp and text/plain.

-- 
Ian Bell                                           T U R N P I K E  Ltd

Date: Tue, 17 Feb 1998 13:30:05 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

On Mon, 16 Feb 1998, Chris Newman <[email-masked]> 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,...). 

> there is an existing text media type which encodes
>paragraph semantics in a human friendly way (RFC 1896),

text/enriched leaves too many footprints for mixed audiences; in
particular quoted text has to be double-spaced or visible commands have
to be added.

However...

On Mon, 16 Feb 1998, Ned Freed <[email-masked]> writes
>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.

...I take the point that defining (yet) another text type will probably
not succeed (although I thought that its suitability for non-MIME
recipients could interest vendors who support both news and mail).

-- 
Ian Bell                                           T U R N P I K E  Ltd

Date: Tue, 17 Feb 1998 10:41:11 +0100
To: Ned Freed <[email-masked]>, Jacob Palme <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Cc: [email-masked]
Sender: [email-masked]

>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: [email-masked]
I am working for Maxware (www.maxware.no) as of Dec 1, 1997

Date: Mon, 16 Feb 1998 23:57:03 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

However, we also have substantial implementation experience that says people
_are_ willing to add a label to the text they generate. Specifically, we've
seen wide deployment of "Content-type: text/plain; charset=whatever" labels on
the Internet.

Text/paragraph is, after all, a widely used "native" text format on quite a
platforms. It is entirely reasonable to expect it to "leak out" into email on a
regular basis.

Now, nobody is claiming for a minute that text/paragraph is a great format that
should be used in preference to, say, text/enriched or text/html. It isn't.
However, many of us, myself included, have battled against the ongoing use of
text/paragraph, to no avail. So, given that we have to live with it, at least
let's try to get it labelled so we can handle it intelligently.

				Ned

Date: Mon, 16 Feb 1998 14:31:40 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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

Date: Mon, 16 Feb 1998 14:16:24 -0600 (CST)
From: Rick Troth <[email-masked]>
To: Ian Bell <[email-masked]>
cc: [email-masked]
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

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). 
 
> -- 
> Ian Bell                                           T U R N P I K E  Ltd
 
	Thanks for your constructive thoughts. 
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Mon, 16 Feb 1998 16:27:54 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

On Mon, 16 Feb 1998, ruth moulton <[email-masked]> 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.

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

It may be (largely) legible, but if you used non-MIME software you would
probably agree that it is unsuitable. MIME has got a very bad name over
large sections of UseNet solely because QP has leaked out into the non-
MIME world.

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

The advantage of my version of text/paragraph over the version defined
in <draft-newman-mime-textpara-00.txt> is that it behaves better when
read by non-MIME MUAs or when read by MIME MUAs that do not support
text/paragraph. Another advantage is that it _specifies_ which lines
should be wrapped and which lines shouldn't.

-- 
Ian Bell                                           T U R N P I K E  Ltd

Date: Mon, 16 Feb 1998 17:50:48 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

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 <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Mon, 16 Feb 1998 15:23:15 GMT
From: ruth moulton <[email-masked]>
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Subject: Content-Type: text/paragraph. An alternative proposal
Cc: [email-masked]
Disposition-notification-to: [email-masked]
Sender: [email-masked]

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

-- 

Date: Mon, 16 Feb 1998 13:13:47 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Content-Type: text/paragraph. An alternative proposal
Sender: [email-masked]

>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
define a media type that caters for the real need: the ability to allow
compliant software to "know" whether lines may or may not be wrapped in
a backwards-compatible manner.

To be truly backwards compatible, a text/paragraph message body should
be displayed to a user of current MIME-compliant software in exactly the
same way as it would have been if it had been sent text/plain in the
first place. This means that there must be a limit on the length of
lines that are sent (probably 72 characters) and there must be no
visible "mark up" used to encode the various types of line endings.

The two different line types commonly found in mail or news are
those with pre-formatted line-breaks which are not expected to be
wrapped (quoted lines, signature lines including "-- " itself) and lines
containing new material from the author which are expected to be
wrapped. Other lines include lines of UUencoded material and lines
produced by PGP.

For the line-break encoding to be invisible to the end-user, it seems to
me that the encoding must be done by using trailing white space.

Thus, my proposal for text/paragraph would be that:

   significant line-breaks terminating pre-formatted lines would be
   encoded by preceding the CRLF with zero or one space character (the
   imprecision here being to cater for "-- ").

   significant line-breaks terminating lines ("paragraphs") intended to
   be wrapped by the viewing MUA would be encoded by preceding the CRLF
   by precisely two space characters.

   non-significant line-breaks ("soft" end-of-lines) inserted by the
   sending MUA for backwards-compatibility would be encoded by preceding
   the CRLF by three space characters. All "paragraphs" to be wrapped
   must be split into lines of no more than 72 characters using this
   "soft" end of line mechanism.

   when quoting from a message sent in text/paragraph, _all_ line-breaks
   (including soft eols) should be treated as pre-formatted, significant
   line-breaks and the trailing spaces encoding line-breaks within
   paragraphs should be removed. This will lead to the proper nesting of
   quoted material whether all MUAs in the conversation thread recognize
   text/paragraph or not.

Encoding considerations:        

   text/paragraph messages would be entirely suitable for 7/8-bit
   encoding whatever the length of the lines in the "paragraphs".
   Indeed, if a message is suitable for 7-bit transmission with the
   default character set, it could even be safely sent to non-MIME
   recipients or arenas (especially UseNet).

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

From: [email-masked]
Date: Sun, 15 Feb 1998 08:54:18 +0100 (MET)
To: [email-masked]
Subject: Do You Like New Inventions?
Reply-To: [email-masked]
Comments: Authenticated Sender is <[email-masked]>
Sender: [email-masked]

Hello my name is Steve,

  I'm the Inventor for Sinner Enterprises and a few other Companies. Do 
you like new Inventions? If so come visit our website.

http://www.wj.net/le/sinner/index.html

  Come see our new, hot and dynamic Carpentry, Dry Wall and Handy Man 
Layout Tool. It cuts work time considerably and none of our products are 
sold in stores.

  We also have 25 newly Invented (Family Interactive) Board Games. Some 
up and some coming, and some as low as $9.95. Our Games are designed to 
bring the Family and Friends together for a fun filled night of 
laughter. Nothing brings the Family together better than the Traditional 
non-computer Board Games.

  If you come for a visit we will give you a free website with no 
strings attached, yours for a life time. And you dont have to own your 
own computer, if you know how to type an address into the computer to 
access the net, then you already have enough knowlage to use our easy 
step by step page wizard to build it yourself.

http://www.wj.net/sinner/index.html

  If you are an Opportunity seeker we'll show you a push button Business 
that runs on Automatic Pilot, even as you sleep you're raking in the 
bread.

  Take time to play our Free Game, if you win you'll get $1.00 off the 
purchase of your first Board Game.

  I hope I was not to boring? My advise in life is don't take any wooden 
pennies. I tried to spend some at the local dollar store and all they 
did was laugh at me. ( Go Figure) Ha!

http://www.wj.net/le/sinner/index.html