Subject: Re: format=flowed : why not use HTML?
From: Chris Newman <[email-masked]>
To: [email-masked]
Date: Mon, 31 Aug 1998 19:32:16 -0700 (PDT)

On Thu, 20 Aug 1998, Dave Crocker wrote:
> 2.  text/paragraph

I hereby withdraw the text/paragraph proposal and throw my support behind
the format=flowed proposal. 

It has been demonstrated that the text/paragraph proposal can cause harm
to the installed base (where harm is defined as making things harder for
end users).  Regardless of the intent, I think this makes text/paragraph a
non-starter for this problem.

The format=flowed proposal, however, appears to have no negative impact on
the installed base.  It may or may not have a positive impact on the
infrastructure (including both old and new clients) -- depending on how
many of the offending paragraph-formatted text generating clients switch
to using format=flowed, and how many non-80-column clients start rendering
format=flowed properly. 

Before I'd be willing to support a proposed standard last call on
format=flowed, I'd want to make sure there's strong language discouraging
the use of quoted-printable with it, and that we've had a reasonable
demonstration that it doesn't cause harm to the installed base.

		- Chris

Date: Sat, 29 Aug 1998 15:17:55 -0700
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New mailing list for discussing mail header registry
Sender: [email-masked]

There is a new mailing list for discussing draft-ietf-drums-MHRegistry and
how to set up the registry. To add yourself to the list, send a message to:
     [email-masked]
with the word "subscribe" in the body of the message. 

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 26 Aug 1998 22:02:50 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Standard for quoting in plain-text messages.
Sender: [email-masked]

At 11.18 +0200 98-08-18, Ian Bell wrote:
> > : ian: randy> } This paragraph has been quoted five
>times using quoting conventions often seen. How will you
>display it correctly, let alone reply and quote correctly:
>especially if the user wants to split the paragraph in two?
>
>
> The problem of quoted text being badly displayed and badly requoted will
> have become a consequence of a published standard rather than the
> consequence of a non-conformant MUA breaking text/plain - much worse IMO.

Perhaps there should be a standard for how to do quoting in
plain text (not HTML) messages. There are many bad
implementations of this. For example, I have seen
implementations which keep Quoted-Printable codes in quoted
text, while the new message is sent without
qouted-printable encoding, or keeps text in other character
sets in the quoted text than in the rest of the message,
and without any ISO 2022 codes to indicate the switch
between character sets.
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

To: [email-masked]
Subject: Re: format=flowed : why not use HTML? 
Date: Wed, 26 Aug 1998 19:21:27 -0700
From: Evan Kirshenbaum <[email-masked]>
Sender: [email-masked]

> Excerpts from bulk.interesting.lists: 20-Aug-98 Re: format=flowed : why
> not.. Chris [email-masked] (1588*)
> 
> > In hindsight, we should have developed a markup language using
> > tricks like _italics_, *bold* and >excerpt for email, so that the
> > markup language itself would be plain text.  Even that would
> > require style-run merging, but it probably would have worked.
> > Unfortunately, it's too late to introduce something like that now.
> 
> It seems to me that something like this was actually discussed early
> on in the MIME drafting.  I don't remember why it lost out, but I do
> remember that it turned out to be a lot more complicated than it
> sounded.

If anybody is interested in that last go-round way back in '93, the
proposal that Bill Janssen and I put together (which we called
"text/simplemail") can be found at

  http://www.hpl.hp.com/personal/Evan_Kirshenbaum/SimpleMail/rfc.ps

-- 
Evan Kirshenbaum                       +------------------------------------
    HP Laboratories                    |"Revolution" has many definitions.
    1501 Page Mill Road, Building 1U   |From the looks of this, I'd say
    Palo Alto, CA  94304               |"going around in circles" comes
                                       |closest to applying...
    [email-masked]             |           Richard M. Hartman
    (650)857-7572

    http://www.hpl.hp.com/personal/Evan_Kirshenbaum/

To: Rick Troth <[email-masked]>
Cc: [email-masked]
Subject: Re: 8BITMIME to 7BIT 
From: [email-masked]
Date: Tue, 25 Aug 1998 15:16:47 -0400
Sender: [email-masked]

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

On Tue, 25 Aug 1998 12:34:31 CDT, Rick Troth said:
> 	I've always wanted a signature/validation scheme that 
> would intentionally  (not in the content, only in the signing logic) 
>  
> 		o discard trailing white space 
>  
> 		o unify all other white space 
> 		  (any number of TABs or SPACEs make one instance) 
>  
> 		o unify paragraph breaks 
> 		  (two blank lines, one blank line, same thing) 

Unfortunately, the only way to do this and Get It Right is to
define a canonical form that the signature is computed over. The
problem is that you *want* a digital signature to have the property
that changing even a single character invalidates the integrity
check.  If this were not so, you could envision ALL sorts of mayhem
caused by one-digit additions/subtractions to an EDI message
(Hmm.. instead of billing me $1198.45, bill me $198.43... ;)

You want to be careful too - consider shipping a digitally signed
table of tab-delimited fields. These would be VERY different:

1134<TAB><TAB>45<TAB>9<CR>
1134<TAB>45<TAB><TAB>9<CR>

but would sign the same.

In any case, I would suggest that cut-and-pasting of a digitally
signed object *should* invalidate the signature.  Think about it. ;)

I'm pretty sure that Rick saw my posting a few weeks ago (I think on
the MAILBOOK list) wherein I hand-waved about quoting digitally signed
text - the upshot being that the only way to make it Really Work Right
is to use a multipart/quoted where the original object is included, and
then we use a markup language of tags similar in form to

<start-octet-in-original><length quoted>Annotation<end>

and then possibly signing that as well.

Hey, it's just a straw-man.. COmments? ;)

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

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

--==_Exmh_-1006029208P--

Date: Tue, 25 Aug 1998 12:34:31 -0500 (CDT)
From: Rick Troth <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: 8BITMIME to 7BIT
Sender: [email-masked]

> The idea to define a way of computing security and identity
> hash sums which will be the same with certain common
> conversions which might occur on a message is great if you
> can make it work.   ... 
 
	I've always wanted a signature/validation scheme that 
would intentionally  (not in the content, only in the signing logic) 
 
		o discard trailing white space 
 
		o unify all other white space 
		  (any number of TABs or SPACEs make one instance) 
 
		o unify paragraph breaks 
		  (two blank lines, one blank line, same thing) 
 
	And the justification is that I want to be able to 
 
		+ cut-n-paste between unlike windows and applications 
 
		+ scan printed matter 
 
	and have duly signed text still pass validation. 
 
	These boxes were built to serve us,  not the other way around. 
We generate  phone calls,  customer frustration,  and piddly work for 
ourselves when we build-in dependence on things that the machine can see 
but we cannot see. 
 
	Interoperability is more important than compatibility. 
Interoperability opens the door to the next level of technology. 
The very reason why the Internet has succeeded is because of inter-
operability,  not because it can  "still exist while in tatters". 
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Fri, 21 Aug 1998 11:52:23 -0400 (EDT)
From: Nathaniel Borenstein <[email-masked]>
To: Daniel Glazman <[email-masked]>, Chris Newman <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
CC: [email-masked]
Sender: [email-masked]

Excerpts from bulk.interesting.lists: 20-Aug-98 Re: format=flowed : why
not.. Chris [email-masked] (1588*)

> In hindsight, we should have developed a markup language using tricks like
> _italics_, *bold* and >excerpt for email, so that the markup language
> itself would be plain text.  Even that would require style-run merging,
> but it probably would have worked.  Unfortunately, it's too late to
> introduce something like that now. 

It seems to me that something like this was actually discussed early on
in the MIME drafting.  I don't remember why it lost out, but I do
remember that it turned out to be a lot more complicated than it sounded.

Excerpts from bulk.interesting.lists: 20-Aug-98 Re: format=flowed : why
not.. [email-masked] (2043*)

> Personally, I'm more and more convinced that we have a moral *obligation*
> to produce something that *will* irritate the customers of those vendors
> that Cant Get It Right.

I'm very sympathetic to this argument, but I fear that in practice it
might work out very badly (if, for example, one concluded that a market
leader was in the "can't get it right" category).  Forcing another MUA
upgrade on users (like the introduction of MIME in the first place)
should not be out of the question, but it certainly shouldn't be entered
into lightly.  -- Nathaniel
--------
Practice gives duration to problems.  Practice is total inattention.  Never
practise:  you can only practise mistakes.  Learning is always new.
		-- Krishnamurti
Nathaniel Borenstein <[email-masked]>

Date: Fri, 21 Aug 1998 13:09:52 -0700
To: Rick Troth <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: [email-masked]
Sender: [email-masked]

Yeah, but you can't blame MUA for that :-), and everyone understands why
it's happening and can easily control it if they want to.

LL

At 2:57 PM -0500 8/21/98, Rick Troth wrote:
>> Because people get mad at MUA vendors when they see markup crud
>> in their mail messages. Same situation as QP encoding.
>
>	BUT ... those same users all too often wind up
>inserting their own  "markup crud"  when they see their buddies
>doing so manually.   *grin*
>
>> LL
>
>--
>Rick Troth at La Casita, Houston, Texas, USA
>

Date: Fri, 21 Aug 1998 14:57:56 -0500 (CDT)
From: Rick Troth <[email-masked]>
To: Laurence Lundblade <[email-masked]>
cc: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

> Because people get mad at MUA vendors when they see markup crud 
> in their mail messages. Same situation as QP encoding.
 
	BUT ... those same users all too often wind up 
inserting their own  "markup crud"  when they see their buddies 
doing so manually.   *grin* 
 
> LL
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Fri, 21 Aug 1998 14:55:31 -0500 (CDT)
From: Rick Troth <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

> Why not just use 
> "recipient friendly HTML" for such cases? 
 
	And the operative phrase here is  "recipient friendly". 
 
	I'm with you,  Keith.   But the persuasion in 
some of the responses is strong.   So I'll fall back to the 
Dave Clark rule,  rough concensus and running code,  and ask you 
to produce some running code that generates  "recipient friendly HTML". 
Do that,  and you may find some concensus. 
 
> <p>
> Keith
> </html>
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Fri, 21 Aug 1998 11:58:37 -0700
To: Dave Crocker <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: [email-masked]
Sender: [email-masked]

At 11:20 PM -0700 8/20/98, Dave Crocker wrote:
>Well, I've been watching the exchange.
>
>Let me see if I understand the arguments:
>
>
>1.  text/html (or other html use)
>
>For:
>It is supported in some user agents already.  If has more than enough power
>for the paragraph wrapping.
>
>Against:
>It is supported in ONLY SOME user agents already.  It is very ugly when
>seen with user agents that don't support html.

I would add that it is incompatible with plain text in other situations
such as grepping your spool file and automatic processing by scripts.

For example one might run a mailing list that forces all HTML postings to
plain text or maybe just plain rejects them. I would like to see the format
we settle on be allowed in such a situation.

>2.  text/paragraph
>
>For:
>simple.  sufficient.  no extra (formatting) data in text.
>
>Against:
>New text/ subtype gets mishandled when unknown to UA.  (sigh.)
>
>
>3.  text/plain format=flowed
>
>For:
>simple.  sufficient.  no extra (formatting) data in text.  does not
>misbehave with UAs that don't recognize the parameter.
>
>Against:
>yet-another mechanism, when text/html is probably going to take over
>(eventually).

I don't want to make a big argument about it because I think the argument
for this option stands without it, but my thought would be that text/html
will never completely take over. Plain text is just lower cost and simpler
and easier in so many situations.

LL

Date: Thu, 20 Aug 1998 23:20:22 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Well, I've been watching the exchange.

Let me see if I understand the arguments:

1.  text/html (or other html use)

For:
It is supported in some user agents already.  If has more than enough power
for the paragraph wrapping.

Against:
It is supported in ONLY SOME user agents already.  It is very ugly when
seen with user agents that don't support html.

2.  text/paragraph

For:
simple.  sufficient.  no extra (formatting) data in text.

Against:
New text/ subtype gets mishandled when unknown to UA.  (sigh.)

3.  text/plain format=flowed

For:
simple.  sufficient.  no extra (formatting) data in text.  does not
misbehave with UAs that don't recognize the parameter.

Against:
yet-another mechanism, when text/html is probably going to take over
(eventually).

Concerning text/html, one could argue that it is only a matter of time
before it will be widely supported.  It is probably even reasonable to
claim that it will eventually be the default 'text' encoding mode for
users.  I suspect that this will be statistically true in relatively few
years, myself.  However, "reasonable" does not mean certain and the
downside of being wrong, even for a short time, is quite a few very angry
users.

If the details of my 1, 2 and 3 summary, above, are correct, then number 3
looks painless, easy and sufficient.  sounds like a win.

What did I miss?

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave CROCKER                            <mailto:[email-masked]>

+1(408)246 8253          BRANDENBURG CONSULTING           +60(19)3299 445

675 Spruce Drive                                      P. O.  Box 296, UPM
Sunnyvale, CA 94086       www.brandenburg.com     Serdang, Selangor 43400
United States            Fax:  +1 408 273 6464                   Malaysia

Date: Thu, 20 Aug 1998 20:14:04 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
To: Keith Moore <[email-masked]>
Cc: Randall Gellens <[email-masked]>, "John  W. Noerenberg" <[email-masked]>, Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > > I have trouble understanding "not fully text/plain compatible"
> >
> > It looks like hell when treated as text/plain.

> or to put it another way, the signal-to-noise ratio is really low
> when treated as text/plain

> or maybe even "it doesn't look like I think it should."

> most quoted-printable text is not unreadable, or even that difficult
> to read.  but it annoys people anyway.

Absolutely, and it is nothing compared to typical HTML, where the content
may be completely obscured.

				Ned

From: Keith Moore <[email-masked]>
To: Randall Gellens <[email-masked]>
cc: "John  W. Noerenberg" <[email-masked]>, Keith Moore <[email-masked]>, Pete Resnick <[email-masked]>, Chris Newman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: format=flowed : why not use HTML? 
Date: Thu, 20 Aug 1998 22:27:50 -0400
Sender: [email-masked]

> > I have trouble understanding "not fully text/plain compatible"
> 
> It looks like hell when treated as text/plain.

or to put it another way, the signal-to-noise ratio is really low
when treated as text/plain

or maybe even "it doesn't look like I think it should."

most quoted-printable text is not unreadable, or even that difficult
to read.  but it annoys people anyway.

Keith

Date: Thu, 20 Aug 1998 19:00:01 -0700
To: "John  W. Noerenberg" <[email-masked]>, Keith Moore <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:11 PM -0500 8/20/98, John  W. Noerenberg wrote:

> I have trouble understanding "not fully text/plain compatible"

It looks like hell when treated as text/plain.

Date: Thu, 20 Aug 1998 12:11:38 -0500
To: Keith Moore <[email-masked]>
From: "John  W. Noerenberg" <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

--============_-1308459029==_ma============
Content-Type: text/plain; charset="us-ascii"

At 2:49 PM -0400 8/19/98, Keith Moore wrote:
>> Text/enriched is
>> probably more widely deployed in mail programs than text/html, it has a
>> much simpler syntax (only "<<" for quoting the "<" symbol and "<nofill>"
>> for doing forced-wrap text), and still people wouldn't accept it, let alone
>> generate it reasonably. I think using any kind of internal markup that is
>> not fully text/plain compatible is a losing battle.
>
>Okay, so this really is the quoted-printable problem all over again.
>People won't generate that reasonably either...though I've always
>wondered if this is because it seems too difficult, or they haven't
>tried, or they didn't think of it, or they just don't care.

It has always seemed to me the real difficulty was senders lack confidence
that receivers will be able to render the message as the sender intended.
I don't believe this results from the inadequacy of the protocols we've
devised.  Rather it comes from users' unfamiliarity, and from their
perception the protocols aren't always "there".

Even though this community has been working on MIME-related issues for
well-nigh a decade, for the overwhelming majority this is still new.  Heck,
just e-mail is new for many.  Couple this with our struggle to find idioms
that make e-mail markup intuitively easy to employ and to render, and you
have the situation that most people use these tools tentatively with the
expectation something will go wrong.

I have trouble understanding "not fully text/plain compatible".  text/html
and text/enriched code their directives in plain text.  I'm not sure how
much more compatible we can make them.  The directives are messages at a
different level than the message between sender and receiver.  Encoding
them in the whole package used to convey the message is our only vehicle.
Negotiation between the sender and receiver over message encoding is not
possible in a store-and-forward environment.

We could have adopted a different strategy than including directives
in-line, but those methods are not without their problems.  text/html and
text/enriched are reasonable, pragmatic choices.

The underlying problem in discussions like this one is when the different
levels are exposed, users' assumptions about their environment are
violated.  Those events weaken users' trust in the protocols.  Because this
occurs too frequently in typical correspondence, we still lack faith in our
protocols' design.  When the environment becomes the same for all users -
employment of text/html and/or text/enriched is consistent and routine,
then we'll no longer have this discussion.

As a society, we don't really question the universal availability or
suitability of pen and paper.  Yet there was a time where its applicability
to convey a message was doubted.  So it will be for text/html.

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------
--============_-1308459029==_ma============
Content-Type: text/enriched; charset="us-ascii"

At 2:49 PM -0400 8/19/98, Keith Moore wrote:

>> Text/enriched is

>> probably more widely deployed in mail programs than text/html, it
has a

>> much simpler syntax (only "<<<<" for quoting the "<<" symbol and
"<<nofill>"

>> for doing forced-wrap text), and still people wouldn't accept it,
let alone

>> generate it reasonably. I think using any kind of internal markup
that is

>> not fully text/plain compatible is a losing battle.

>

>Okay, so this really is the quoted-printable problem all over again.

>People won't generate that reasonably either...though I've always

>wondered if this is because it seems too difficult, or they haven't

>tried, or they didn't think of it, or they just don't care.

It has always seemed to me the real difficulty was senders lack
confidence that receivers will be able to render the message as the
sender intended.  I don't believe this results from the inadequacy of
the protocols we've devised.  Rather it comes from users'
unfamiliarity, and from their perception the protocols aren't always
"there".

Even though this community has been working on MIME-related issues for
well-nigh a decade, for the overwhelming majority this is still new. 
Heck, just e-mail is new for many.  Couple this with our struggle to
find idioms that make e-mail markup intuitively easy to employ and to
render, and you have the situation that most people use these tools
tentatively with the expectation something will go wrong.

I have trouble understanding "not fully text/plain compatible". 
text/html and text/enriched code their directives in plain text.  I'm
not sure how much more compatible we can make them.  The directives are
messages <italic>at a different level </italic>than the message between
sender and receiver.  Encoding them in the whole package used to convey
the message is our only vehicle.  Negotiation between the sender and
receiver over message encoding is not possible in a store-and-forward
environment.

We could have adopted a different strategy than including directives
in-line, but those methods are not without their problems.  text/html
and text/enriched are reasonable, pragmatic choices.

The underlying problem in discussions like this one is when the
different levels are exposed, users' assumptions about their
environment are violated.  Those events weaken users' trust in the
protocols.  Because this occurs too frequently in typical
correspondence, we still lack faith in our protocols' design.  When the
environment becomes the same for all users - employment of text/html
and/or text/enriched is consistent and routine, then we'll no longer
have this discussion.

As a society, we don't really question the universal availability or
suitability of pen and paper.  Yet there was a time where its
applicability to convey a message was doubted.  So it will be for
text/html.

john noerenberg

[email-masked]

  ----------------------------------------------------------------------

  --if we are to be saved, it will not be by Romans but by saints.

  -- Thomas Cahill, "how the Irish Saved Civilization", 1995

  ----------------------------------------------------------------------

--============_-1308459029==_ma============--

Date: Thu, 20 Aug 1998 14:48:16 -0700
To: [email-masked], Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: [email-masked]
Sender: [email-masked]

At 5:20 PM -0400 8/20/98, [email-masked] wrote:

>If you make handling of text/plain anything other than a simple "while
>(getchar()) putchar();' loop, somebody *will* botch it.

I'm not sure what you are saying, or objecting to, or proposing.

The Format=Flowed proposal allows flowed text to be treated as
text/plain, since it *is* text/plain.

To: Randall Gellens <[email-masked]>
Cc: [email-masked]
Subject: Re: format=flowed : why not use HTML? 
From: [email-masked]
Date: Thu, 20 Aug 1998 17:20:39 -0400
Sender: [email-masked]

--==_Exmh_53438652P
Content-Type: text/plain; charset=us-ascii

On Thu, 20 Aug 1998 12:18:44 PDT, Randall Gellens said:
> There are lots of other problems that would be nice to solve, but
> realistically won't be.  If we can agree on a solution to the most
> basic and simple form of the problem we may have a chance of seeing it
> implemented and deployed, and thus have Internet email made a bit safer
> and more interoperable.  If we try to get fancy, we likely won't agree,
> and certainly won't see successful deployment.

If you make handling of text/plain anything other than a simple
"while (getchar()) putchar();' loop, somebody *will* botch it.
Let's face it - there's two groups of MUA producers: the ones who
will Get It Right (so we may as well come up with a *good* solution
even if more complicated), and the ones who Get It Wrong.

<rant>
Personally, I'm more and more convinced that we have a moral *obligation*
to produce something that *will* irritate the customers of those vendors
that Cant Get It Right.

I know a lot of people get pissed off because I multipart/sign my mail,
but the irritant factor has also gotten a number of people to upgrade.
I had one co-worker who kept whining that his MUA was *totally* unable
to read my mail because it didn't downgrade /signed to /mixed.  I kept
doing it, he finally gave up and changed to another MUA.

Remember all the whining that happened when MIME was first deployed?

Heard anybody whine "What's this 'This is a MIME message'?" lately?

I think it's time for another round.
</rant>

/Valdis (who spent the day hacking up procmailrc rules to automate
responses to people with brokked mail systems)...

--==_Exmh_53438652P
Content-Type: application/pgp-signature

--==_Exmh_53438652P--

Date: Thu, 20 Aug 1998 15:11:06 -0500
To: Jamie Zawinski <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: [email-masked]
Sender: [email-masked]

At 11:32 AM -0700 8/20/98, Jamie Zawinski wrote:

>But the reality is that nobody has even *tried*.

Nonsense.  We have tried with text/enriched.  We do a reasonable job if
people use some restraint.  Could we have tried a lot harder?  Yes. 
Would we have improved the output?  Somewhat (the nesting rule is a
problem, and text with lots of style changes simply
<italic>must</italic> be ugly).

But for HTML, you're right, we didn't try very hard, because it's
<italic>useless</italic>.  It's not a matter of optimization or any
nonsense like that.  I used to think like Chris does, that maybe it
could be done if you're careful.  But it can't.

It's simple, everyday constructs that HTML has to go through gyrations
to display.  Anytime there is more than one space (or, god forbid, a
tab) you get some &nbsp's.  Every hard return is more markup (and
you're really best not even to think about how to get two lines without
whitespace between them).  And of course you can't use <<.

Hopeless, if you want to have any fidelity at all to the original
text.

Date: Thu, 20 Aug 1998 12:18:44 -0700
To: Jamie Zawinski <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

At 10:48 AM -0700 8/20/98, Jamie Zawinski wrote:

>Do you have examples of what you think would render such messages
>unreadable to a viewer who only implemented "simple html"?

This is really besides the point.  The problem we're trying to solve is
fairly simple: a way for text to be (a) *totally* compatible with
text/plain, and (b) able to indicate which lines can be flowed on
receipt.

There are lots of other problems that would be nice to solve, but
realistically won't be.  If we can agree on a solution to the most
basic and simple form of the problem we may have a chance of seeing it
implemented and deployed, and thus have Internet email made a bit safer
and more interoperable.  If we try to get fancy, we likely won't agree,
and certainly won't see successful deployment.

Date: Thu, 20 Aug 1998 11:32:44 -0700
From: Jamie Zawinski <[email-masked]>
Organization: the mystic knights of mozilla, http://www.mozilla.org/
To: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Chris Newman wrote:
> 
> It turns out that *every* client which generates text/enriched or
> text/html results in largely unreadable output, and that includes the
> vendors who gave us assurances about how it would be readable.

This much is true (though I wonder who those assurances came from.)

> It may be possible to make this stuff readable, but it requires very
> careful engineering -- doing things like merging adjacent style runs,
> keeping careful track of the plain-text output column, pushing paragraph
> markers to the right edge, making sure spurious plain-text newlines aren't
> inserted, not generating boilerplate at the beginning and so forth. 

Yes, it requires some care.  It's not what I'd consider rocket science,
however.

> The fact nobody has done this is adequate evidence that it's too hard
> to be practical.

No, it is evidence of no such thing!

If there had seemed to be any *attempt* to do this, and it had just not
worked, then that might be the case.  But the reality is that nobody has
even *tried*.  Presumably because none of the implementors have seen it
as being important enough to spend time on, for whatever reason.

The kinds of things you're talking about are easy to do as a
post-process, I think (it's really just a peephole optimizer, mostly);
perhaps someone who cared deeply about this (pause for dramatic effect)
should code something up and give it away, so that all the horrible
vendors who couldn't be bothered to invent their own solutions to this
problem could instead just drop in this filter and make everyone happy.

I think I understand why most vendors have not found the time to work on
this.  A vendor ships a tool that can display more high-tech messages,
as well as low-tech messages.  What is their incentive to work on making
those high-tech messages readable to people using low-tech mail readers?
Those low-tech users are, by definition, not the customers of the
vendor!  Yes, the vendor's direct customers need to interact with them,
but see, that's an additional level of indirection.  

I think that this is bad, and that backward compatibility is very
important, but it's also easy for me to understand how we got into the
situation we're in today.

> In hindsight, we should have developed a markup language using tricks like
> _italics_, *bold* and >excerpt for email, so that the markup language
> itself would be plain text.  Even that would require style-run merging,
> but it probably would have worked.  Unfortunately, it's too late to
> introduce something like that now.

Brad Templeton (I think) proposed something like that years and years
ago, and came to the conclusion that it didn't really work.  Then later
he came up with ProleText (http://www.clari.net/prole/prolespec.html)
which ClariNet has been using for a couple of years.  (For those who
haven't seen it, it's a way of encoding HTML markup using only
end-of-line whitespace.)

-- 
Jamie Zawinski             http://www.jwz.org/              about:jwz

Date: Thu, 20 Aug 1998 13:30:44 -0500
To: Chris Newman <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Daniel Glazman <[email-masked]>, [email-masked]
Sender: [email-masked]

On 8/20/98 at 10:49 AM -0700, Chris Newman wrote:

>It turns out that *every* client which generates text/enriched or
>text/html results in largely unreadable output, and that includes the
>vendors who gave us assurances about how it would be readable.

OK, let me at least put in a tacit objection to this. Though HTML cannot be
made readable to save its life, simply because each multiple space must be
encoded as &nbsp;, each quote and angle bracket must be similarly encoded,
and each line break *requires* a directive, the same is simply not true of
text/enriched. In fact, we follow everyone of the following directives in
text/enriched:

>It may be possible to make this stuff readable, but it requires very
>careful engineering -- doing things like merging adjacent style runs,
>keeping careful track of the plain-text output column, pushing paragraph
>markers to the right edge, making sure spurious plain-text newlines aren't
>inserted, not generating boilerplate at the beginning and so forth.  The
>fact nobody has done this is adequate evidence that it's too hard to be
>practical.

What makes text/enriched unreadable is that once users find it, they
inevitably decide that they need to use every feature of it: As soon as you
include a font or a color change, you generate a horrible looking directive
for every occurance. Also, the quoting convention is a pain to display in
plain text. Other than that, it is perfectly easy to generate simple
text/enriched, and at least we are able to do it very straightforwardly.

HTML is a lost cause. There is no way to have anything that's vaugley
readable as plain text and legal HTML.

But even with text/enriched, I still don't think it solves the basic
problem: People want wrapped text with a quoting convention that can be
dealt with by fancy mailers as will as /bin/mail without metamail
installed. This solution is an elegant way to get there. No formal markup
is at all reasonable to solve the problem.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

Date: Thu, 20 Aug 1998 10:48:46 -0700
To: Keith Moore <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Chris Newman <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:07 PM -0400 8/20/98, Keith Moore wrote:
>> On Wed, 19 Aug 1998, Keith Moore wrote:
>> > > One certainly can't re-use the text/html label for such a profile as
>>there
>> > > are deployed clients which deliberately don't display text/html to
>>the user
>> > > because it's almost always unreadable (I'm using one such client).
>> >
>> > Surely this is configurable?
>>
>> Not only is it not configurable in my client, but it's quite clear that
>> any new text subtype will be treated as an attachment and not displayed by
>> a significant number of deployed clients.  That means if we want a
>> chance at fixing the text/plain problem, the fix will also have to be
>> called text/plain.  Quite unfortunate.
>
>That's a bit of a surprise.  Most of the MIME UAs I know of are
>configurable on a per-content-type basis.  I realize that there
>are a lot of deployed clients that don't do the text/foo default
>according to the specs, but I'm surprised if most of them can't
>define specific handling for text/foo.
>

I don't think requiring configuration is an option here. Most people have
no idea how to configure handlers for different media types. Most rely on
the three letter file extension or the Macintosh type/creator.

I believe for this text format to fly is has to seemlessly work with
existing mailers.

LL

BTW, I think it was probably text/html that created this problem. It should
have been application/html. Then it would still be safe to display unknown
text subtypes.

Date: Thu, 20 Aug 1998 10:48:30 -0700
From: Jamie Zawinski <[email-masked]>
Organization: the mystic knights of mozilla, http://www.mozilla.org/
To: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Chris Newman wrote:
> 
> If a simple profile of HTML were used in an interactive protocol where a
> profile violation would be immediately rejected with an error, I'd have no
> problem with it.  The problem is that a profile of HTML is pointless
> without strict enforcement of the profile because people will use any HTML
> feature they can get away with.

Do you have examples of what you think would render such messages
unreadable to a viewer who only implemented "simple html"?

If a viewer supported something analagous to the minimal set of
text/enriched tags (say: P, BR, PRE, and character entities, ok, and
maybe UL and TT) then I believe that no matter how hairy the HTML got,
it would still be readable (unless they were doing something like
embedding text in GIFs, which makes it not really be an HTML problem at
all.)

I've seen an awful lot of HTML messages, and a lot of them contain 
some fairly egregious crap -- but I can't recall seeing a single 
message that would have been rendered *less* readable by the removal 
of those non-basic tags.  (The only thing that comes close would be
tables -- but people just don't use tables in day-to-day conversation,
I've never seen one that seemed to have been made on-the-fly.)

-- 
Jamie Zawinski             http://www.jwz.org/              about:jwz

Date: Thu, 20 Aug 1998 10:49:52 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Daniel Glazman <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Thu, 20 Aug 1998, Daniel Glazman wrote:
> Chris Newman wrote:
> > P.S. There is significant evidence that it's too hard to make SGML-based
> > markup recipient friendly.
> 
> Can you please give us examples ? I'd be very happy to read these
> evidences...

The prime examples are text/enriched and text/html.  Both were registered
in the "text" tree only under the condition that the media types would be
generated in such a way that a human would be able to easily read them
without an enriched or html interpretor.  There were grand assurances from
all the client vendors that this would be no problem. 

It turns out that *every* client which generates text/enriched or
text/html results in largely unreadable output, and that includes the
vendors who gave us assurances about how it would be readable.

It may be possible to make this stuff readable, but it requires very
careful engineering -- doing things like merging adjacent style runs,
keeping careful track of the plain-text output column, pushing paragraph
markers to the right edge, making sure spurious plain-text newlines aren't
inserted, not generating boilerplate at the beginning and so forth.  The
fact nobody has done this is adequate evidence that it's too hard to be
practical.

In hindsight, we should have developed a markup language using tricks like
_italics_, *bold* and >excerpt for email, so that the markup language
itself would be plain text.  Even that would require style-run merging,
but it probably would have worked.  Unfortunately, it's too late to
introduce something like that now. 

		- Chris

From: Keith Moore <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: format=flowed : why not use HTML? 
Date: Thu, 20 Aug 1998 12:07:41 -0400
Sender: [email-masked]

> On Wed, 19 Aug 1998, Keith Moore wrote:
> > > One certainly can't re-use the text/html label for such a profile as there 
> > > are deployed clients which deliberately don't display text/html to the user
> > > because it's almost always unreadable (I'm using one such client).
> > 
> > Surely this is configurable?
> 
> Not only is it not configurable in my client, but it's quite clear that
> any new text subtype will be treated as an attachment and not displayed by
> a significant number of deployed clients.  That means if we want a
> chance at fixing the text/plain problem, the fix will also have to be
> called text/plain.  Quite unfortunate.

That's a bit of a surprise.  Most of the MIME UAs I know of are
configurable on a per-content-type basis.  I realize that there
are a lot of deployed clients that don't do the text/foo default
according to the specs, but I'm surprised if most of them can't 
define specific handling for text/foo.

Keith

Date: Thu, 20 Aug 1998 08:53:44 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Wed, 19 Aug 1998, Keith Moore wrote:
> > One certainly can't re-use the text/html label for such a profile as there 
> > are deployed clients which deliberately don't display text/html to the user
> > because it's almost always unreadable (I'm using one such client).
> 
> Surely this is configurable?

Not only is it not configurable in my client, but it's quite clear that
any new text subtype will be treated as an attachment and not displayed by
a significant number of deployed clients.  That means if we want a
chance at fixing the text/plain problem, the fix will also have to be
called text/plain.  Quite unfortunate.

> The impression I'm getting is that HTML has suffered from what I think
> of as "ASN.1 disease" (though it could equally apply to a number of other
> things):  If a technology has a lot more features than is needed to do a
> particular job, those features get used whether they're needed or not.

ASN.1 has fundamental architectural flaws which go well beyond just being
vastly over complicated.  Oddly enough, XML fixes most of the major flaws
in ASN.1 without introducing too many new flaws.

> The results tend to be so ugly that people are biased against any use 
> of the technology, even when such use is reasonable and appropriate.

If a simple profile of HTML were used in an interactive protocol where a
profile violation would be immediately rejected with an error, I'd have no
problem with it.  The problem is that a profile of HTML is pointless
without strict enforcement of the profile because people will use any HTML
feature they can get away with.

		- Chris

Date: Thu, 20 Aug 1998 09:10:46 +0100
From: Daniel Glazman <[email-masked]>
Organization: EDF
To: Jamie Zawinski <[email-masked]>
CC: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Jamie Zawinski wrote:

> Pete Resnick wrote:
> >
> > Text/enriched is much more widely deployed [...] than HTML.
> 
> On what do you base this assertion?  I'm afraid I don't believe it.

I agree 100% with jwz.

I am the moderator of the french newsgroups fr.emplois.*
hierarchy (job offers and requests) and receive about 25% of 500
articles per day sent directly from a SMTP MUA to my moderator's mailbox.
None of them, I repeat : none of them, used text/enriched in the last
three years. These articles come from all over the world.

25%*500*365*3 = 136875. And 0% of 136875 messages is not IMHO "widely
deployed"...

BTW, about 20% of 136875 are made of a multipart/mixed with a text/plain
and a text/html...

Furthermore, since 1992, the number of messages I got in my personal mailbox
using the text/richtext or text/enriched is less than 10 (ten).

In fact, Pete is right : text/enriched is widely deployed. But is
not widely used.

</Daniel>

Date: Thu, 20 Aug 1998 08:54:04 +0100
From: Daniel Glazman <[email-masked]>
Organization: EDF
To: Chris Newman <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Chris Newman wrote:

> P.S. There is significant evidence that it's too hard to make SGML-based
> markup recipient friendly.

Can you please give us examples ? I'd be very happy to read these
evidences...

Oh, BTW, HTML is a SGML dtd and I'm sure you can achieve navigation
in this SGML-based markup application from a user's point of view.

</Daniel>

Date: Wed, 19 Aug 1998 18:06:36 -0700
To: Pete Resnick <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Laurence Lundblade <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

At 7:31 PM -0500 8/19/98, Pete Resnick wrote:

>On 8/19/98 at 4:52 PM -0700, Randall Gellens wrote:
>
>>>We could say that.
>>>But then there'd be no way to represent what I've typed here.
>>>I don't know, but that doesn't seem like a good thing to me.
>>>
>>>Seriously, though, even though all we will be missing is the ability to
>>>"type haikus", it still seems like single line paragraphs come up enough
>>>that we should deal with them somehow.
>>
>>If you want to compose haikus, fine, send them as fixed lines.  You
>>don't want the recipient folding them anyway, do you?
>
>No, that's my point. 1 line paragraphs should be eligible for folding. I
>want all three of those lines above eligible for folding. I don't want
>someone to give me a horizontal scrollbar to display the above on a small
>display.

Ah, you want to be able to send a series of single-line paragraphs with
no separating blank lines and mark them as flowed.  Yes, the proposal
does not allow that, but I don't think it's worth adding complexity to
solve.  You can always put blank lines between your paragraphs, or live
with them being sent as fixed.  On the whole, we'd still be better off
then we are today.  I don't think we can solve everything, but if we
can solve the majority of cases, with a very simple mechanism, I think
it's worth trying.

Date: Wed, 19 Aug 1998 19:31:57 -0500
To: Randall Gellens <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Randall Gellens <[email-masked]>, Laurence Lundblade <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

On 8/19/98 at 4:52 PM -0700, Randall Gellens wrote:

>>We could say that.
>>But then there'd be no way to represent what I've typed here.
>>I don't know, but that doesn't seem like a good thing to me.
>>
>>Seriously, though, even though all we will be missing is the ability to
>>"type haikus", it still seems like single line paragraphs come up enough
>>that we should deal with them somehow.
>
>If you want to compose haikus, fine, send them as fixed lines.  You
>don't want the recipient folding them anyway, do you?

No, that's my point. 1 line paragraphs should be eligible for folding. I
want all three of those lines above eligible for folding. I don't want
someone to give me a horizontal scrollbar to display the above on a small
display.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

Date: Wed, 19 Aug 1998 17:13:32 -0700
To: Pete Resnick <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Randall Gellens <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

--============_-1308550477==_ma============
Content-Type: text/plain; charset="us-ascii"

At 6:39 PM -0500 8/19/98, Pete Resnick wrote:
>On 8/19/98 at 3:30 PM -0700, Randall Gellens wrote:
>
>>Do we need to?  The draft says that SP-CRLF means "this line can be
>>flowed with the next".  Since paragraphs are typically separated by a
>>blank line, a single-line paragraph will end in SP-CRLF-CRLF, that is,
>>a flowed line followed by an empty non-flowed line.
>
>We could say that.
>But then there'd be no way to represent what I've typed here.
>I don't know, but that doesn't seem like a good thing to me.
>
>Seriously, though, even though all we will be missing is the ability to
>"type haikus", it still seems like single line paragraphs come up enough
>that we should deal with them somehow.
>
You didn't say what you wanted flowed in your example and what you didn't.
Seems there's no problem with encoding what you wrote unless we're worried
about 17 or less column displays. The encoding would be:

We could say that.\r\n
But then there'd be no way to represent what I've typed here. \r\n
I don't know, but that doesn't seem like a good thing to me.\r\n

What I think we can't do is prevent wrapping of the following on a 16
column or less display:

Hey you. Don't
muck with my
three line table.

I not worried about this because it's no worse than we do today. If we
could express via the extra space or some other mechanism that the above
text is not to be wrapped then the possible behaviors on a 10 line display
are:

1) horizontal scrolling. This would be optimal and correct, but it'a pain
to implement.

2) truncate at 10 lines. Also correct, but no MUA author in their right
mind would do this unless they like upset users.

3) wrap. This is what we do now with text/plain and what we would get out
of format=flowed the way it's currently proposed. As far as I know most
MUAs do this now except for Netscape that does the horizontal scroll bar.

Am I missing something?

LL
--============_-1308550477==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: draft-gellens-format-00</title></head><body>
<div>At 6:39 PM -0500 8/19/98, Pete Resnick wrote:</div>
<div>&gt;On 8/19/98 at 3:30 PM -0700, Randall Gellens wrote:<br>
&gt;<br>
&gt;&gt;Do we need to?&nbsp; The draft says that SP-CRLF means
&quot;this line can be<br>
&gt;&gt;flowed with the next&quot;.&nbsp; Since paragraphs are
typically separated by a<br>
&gt;&gt;blank line, a single-line paragraph will end in SP-CRLF-CRLF,
that is,<br>
&gt;&gt;a flowed line followed by an empty non-flowed line.<br>
&gt;<br>
&gt;We could say that.<br>
&gt;But then there'd be no way to represent what I've typed here.<br>
&gt;I don't know, but that doesn't seem like a good thing to me.<br>
&gt;<br>
&gt;Seriously, though, even though all we will be missing is the
ability to<br>
&gt;&quot;type haikus&quot;, it still seems like single line
paragraphs come up enough<br>
&gt;that we should deal with them somehow.<br>
&gt;</div>
<div>You didn't say what you wanted flowed in your example and what
you didn't. Seems there's no problem with encoding what you wrote
unless we're worried about 17 or less column displays. The encoding
would be:</div>
<div><br></div>
<div><tt>We could say that.\r\n</tt></div>
<div><tt>But then there'd be no way to represent what I've typed
here. \r\n<br>
I don't know, but that doesn't seem like a good thing to
me.\r\n</tt></div>
<div><br></div>
<div>What I think we can't do is prevent wrapping of the following on
a 16 column or less display:</div>
<div><br></div>
<div><tt>Hey you. Don't</tt></div>
<div><tt>muck with my</tt></div>
<div><tt>three line table.</tt></div>
<div><tt><br></tt></div>
<div>I not worried about this because it's no worse than we do today.
If we could express via the extra space or some other mechanism that
the above text is not to be wrapped then the possible behaviors on a
10 line display are:</div>
<div><br></div>
<div>1) horizontal scrolling. This would be optimal and correct, but
it'a pain to implement.</div>
<div><br></div>
<div>2) truncate at 10 lines. Also correct, but no MUA author in
their right mind would do this unless they like upset users.</div>
<div><br></div>
<div>3) wrap. This is what we do now with text/plain and what we
would get out of format=flowed the way it's currently proposed. As
far as I know most MUAs do this now except for Netscape that does the
horizontal scroll bar.</div>
<div><br></div>
<div>Am I missing something?</div>
<div><br></div>
<div>LL</div>
</body>
</html>
--============_-1308550477==_ma============--

Date: Wed, 19 Aug 1998 16:52:30 -0700
To: Pete Resnick <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Laurence Lundblade <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

At 6:39 PM -0500 8/19/98, Pete Resnick wrote:

>On 8/19/98 at 3:30 PM -0700, Randall Gellens wrote:
>
>>Do we need to?  The draft says that SP-CRLF means "this line can be
>>flowed with the next".  Since paragraphs are typically separated by a
>>blank line, a single-line paragraph will end in SP-CRLF-CRLF, that is,
>>a flowed line followed by an empty non-flowed line.
>
>We could say that.
>But then there'd be no way to represent what I've typed here.
>I don't know, but that doesn't seem like a good thing to me.
>
>Seriously, though, even though all we will be missing is the ability to
>"type haikus", it still seems like single line paragraphs come up enough
>that we should deal with them somehow.

If you want to compose haikus, fine, send them as fixed lines.  You
don't want the recipient folding them anyway, do you?

Date: Wed, 19 Aug 1998 18:39:39 -0500
To: Randall Gellens <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Laurence Lundblade <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

On 8/19/98 at 3:30 PM -0700, Randall Gellens wrote:

>Do we need to?  The draft says that SP-CRLF means "this line can be
>flowed with the next".  Since paragraphs are typically separated by a
>blank line, a single-line paragraph will end in SP-CRLF-CRLF, that is,
>a flowed line followed by an empty non-flowed line.

We could say that.
But then there'd be no way to represent what I've typed here.
I don't know, but that doesn't seem like a good thing to me.

Seriously, though, even though all we will be missing is the ability to
"type haikus", it still seems like single line paragraphs come up enough
that we should deal with them somehow.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

Date: Wed, 19 Aug 1998 15:30:41 -0700
To: Pete Resnick <[email-masked]>, Laurence Lundblade <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

At 3:17 PM -0500 8/19/98, Pete Resnick wrote:

>If we can come up with some way to mark single line paragraphs (two spaces
>at the end of a line? a tab instead of a space?), I think that would
>complete the picture for this document.

Do we need to?  The draft says that SP-CRLF means "this line can be
flowed with the next".  Since paragraphs are typically separated by a
blank line, a single-line paragraph will end in SP-CRLF-CRLF, that is,
a flowed line followed by an empty non-flowed line.

Date: Wed, 19 Aug 1998 13:52:08 -0700
To: Pete Resnick <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

At 3:17 PM -0500 8/19/98, Pete Resnick wrote:
>On 8/19/98 at 11:43 AM -0700, Laurence Lundblade wrote:
>
>>At 3:32 PM +0100 8/14/98, Ian Bell wrote:
>>>
>>>There are actually two sorts of lines that are not terminated by "soft"
>>>line endings: those that form the last lines of paragraphs and those
>>>that are not intended to be wrapped at all. The distinction is vital but
>>>this draft seems to confuse the two.
>
>Actually, the last lines of paragraphs are not the problem: The flowing
>travels with the SP-CRLF at the end of the previous line, so the last line
>of a paragraph always looks like it is attached to the previous line,
>whereas a line that ought not be wrapped is not proceeded with a SP-CRLF.
>The problem is with single-line paragraphs. In those cases, you can't tell
>if it is OK to rewrap it.
>
OK

>>However the solution is to generate different MIME parts for flowed and
>>non-flowed text. I'm not sure how often this will be done in practice, but
>>I feel this is a completely viable option.
>
>I disagree. The idea here was to get rid of crap in MUAs that can't handle
>other than plain text. MIME separators are no bargin in that arena.
>
>If we can come up with some way to mark single line paragraphs (two spaces
>at the end of a line? a tab instead of a space?), I think that would
>complete the picture for this document.

Hmmm. I don't expect this to happen very often. I proposed this more for
completeness than wide spread use. I'm a little reluctant to get more fancy
with flowed format for fear of feature creep and greater exposure to
mangling gateways and such.  This will make generating this text more
complicated.

I would prefer to not include this unless it's considered a big problem.

>>I would suggest that the draft say that all line breaks are ends-of-flows
>>or ends-of-paragraphs and all text is candidate for wrapping. If you want
>>no wrapping (when possible) you should put it in a different MIME entity.
>
>No, this is Chris's complaint about needing double-returns for tables.
>Unacceptable.

I think I should have said all *unescaped* line breaks are end-of-flows.

LL

Date: Wed, 19 Aug 1998 15:17:13 -0500
To: Laurence Lundblade <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

On 8/19/98 at 11:43 AM -0700, Laurence Lundblade wrote:

>At 3:32 PM +0100 8/14/98, Ian Bell wrote:
>>
>>There are actually two sorts of lines that are not terminated by "soft"
>>line endings: those that form the last lines of paragraphs and those
>>that are not intended to be wrapped at all. The distinction is vital but
>>this draft seems to confuse the two.

Actually, the last lines of paragraphs are not the problem: The flowing
travels with the SP-CRLF at the end of the previous line, so the last line
of a paragraph always looks like it is attached to the previous line,
whereas a line that ought not be wrapped is not proceeded with a SP-CRLF.
The problem is with single-line paragraphs. In those cases, you can't tell
if it is OK to rewrap it.

>However the solution is to generate different MIME parts for flowed and
>non-flowed text. I'm not sure how often this will be done in practice, but
>I feel this is a completely viable option.

I disagree. The idea here was to get rid of crap in MUAs that can't handle
other than plain text. MIME separators are no bargin in that arena.

If we can come up with some way to mark single line paragraphs (two spaces
at the end of a line? a tab instead of a space?), I think that would
complete the picture for this document.

>I would suggest that the draft say that all line breaks are ends-of-flows
>or ends-of-paragraphs and all text is candidate for wrapping. If you want
>no wrapping (when possible) you should put it in a different MIME entity.

No, this is Chris's complaint about needing double-returns for tables.
Unacceptable.

>We should also say in the draft that long "words" (runs with no spaces) are
>allowed and should be formatted as best as possible by the receiver.

I don't see real necessity for this, but have no objections.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

Date: Wed, 19 Aug 1998 12:35:36 -0700
To: Laurence Lundblade <[email-masked]>, Ian Bell <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: [email-masked]
Sender: [email-masked]

At 11:43 AM -0700 8/19/98, Laurence Lundblade wrote:

>At 3:32 PM +0100 8/14/98, Ian Bell wrote:
>>
>>There are actually two sorts of lines that are not terminated by "soft"
>>line endings: those that form the last lines of paragraphs and those
>>that are not intended to be wrapped at all. The distinction is vital but
>>this draft seems to confuse the two.
>
>I think in practice we rarely care about this. Simple edit controls don't
>allow you to tell the difference between these two cases. You could use a
>heuristic that counts spaces and decide it's a table if there's multiple
>occurances of multiple spaces, but if you care that much you probably ought
>to use HTML.

The receiver can tell a run of fixed lines from a paragraph.  It's
harder for the sender to know what to generate.  In addition to
Laurence's suggestion, the font could be important (fixed-width fonts
are sent as fixed lines).  Or, if user agents had the ability to select
word-wrap on sections, instead of an entire message, that could be used.

>However the solution is to generate different MIME parts for flowed and
>non-flowed text. I'm not sure how often this will be done in practice, but
>I feel this is a completely viable option.
>
>I would suggest that the draft say that all line breaks are ends-of-flows
>or ends-of-paragraphs and all text is candidate for wrapping. If you want
>no wrapping (when possible) you should put it in a different MIME entity.

That's an interesting idea.  It gets rid of the trailing space issue,
but does make the message slightly harder to read in a non-MIME mailer.

Date: Wed, 19 Aug 1998 12:21:33 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
To: Keith Moore <[email-masked]>
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Chris Newman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > As Ned is so fond of saying, "That dog don't hunt."

> I thought that was Jeff Case's saying...

It is, although I've been known to borrow it...

> > Text/enriched is
> > probably more widely deployed in mail programs than text/html, it has a
> > much simpler syntax (only "<<" for quoting the "<" symbol and "<nofill>"
> > for doing forced-wrap text), and still people wouldn't accept it, let alone
> > generate it reasonably. I think using any kind of internal markup that is
> > not fully text/plain compatible is a losing battle.

> Okay, so this really is the quoted-printable problem all over again.
> People won't generate that reasonably either...though I've always
> wondered if this is because it seems too difficult, or they haven't
> tried, or they didn't think of it, or they just don't care.

Yes, it pretty much is. But a key difference is that Randy has come up with
something that is _completely_ compatible with the existing format.
Quoted-printable, text/enriched, and certainly text/html don't even come close
by comparison. Randy's format has no markup, no funny characters, nothing. Just
some spaces at the ends of lines.

This is as friendly as it gets to existing agents, yet lets more advanced
agents reformat the parts where it is OK to reformat.

				Ned

Date: Wed, 19 Aug 1998 12:21:04 -0700
From: Jamie Zawinski <[email-masked]>
Organization: the mystic knights of mozilla, http://www.mozilla.org/
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Keith Moore wrote:
> 
> Okay, so this really is the quoted-printable problem all over again.
> People won't generate that reasonably either...though I've always
> wondered if this is because it seems too difficult, or they haven't
> tried, or they didn't think of it, or they just don't care.

For the record, as one of the people guilty of writing code that does
the "dumb thing" when generating QP text (breaking at N columns instead
of backing up to the previous word): the reason I did it that way was
that it was easy, and it hadn't occurred to me that it would matter. 

And then, after it was deployed, the loud screaming I heard was "stop
generating QP", not "generate QP that looks better."  So that's where I
focussed my effort: finding ways to avoid generating QP most of the time
(since in the real world, it's hardly ever actually needed) rather than
making it prettier when it is needed.

-- 
Jamie Zawinski             http://www.jwz.org/              about:jwz

Date: Wed, 19 Aug 1998 12:17:54 -0700
From: Jamie Zawinski <[email-masked]>
Organization: the mystic knights of mozilla, http://www.mozilla.org/
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Pete Resnick wrote:
> 
> On 8/19/98 at 11:36 AM -0700, Jamie Zawinski wrote:
> 
> >> Text/enriched is much more widely deployed [...] than HTML.
> >
> >On what do you base this assertion?  I'm afraid I don't believe it.
> 
> You guys support it. We do. Pine does. Anyone with a metamail-compatible
> mail reader supports it. Lots of old MIME-aware mailers support it. AOL
> doesn't royally screw it up anymore; I don't know how strong their support
> for it is.

Does MS support it?  (I don't know.)

How many people do you think realize that Netscape supports it?
I'm guessing "about a hundred."

There are certainly a lot more text/html messages out there than there
have ever been text/enriched messages.  For better or worse.

> Seems pretty widely deployed to me. (On the receiving end we're talking
> about, not the sending end.)

I think you have to look at both...

I really can't get excited about trying to deploy yet another markup
language, even if it's one that has been around (and unused) longer than
HTML.  If you're going to do a markup language at all, it might as well
be HTML. HTML is here, and it's not going away.

-- 
Jamie Zawinski             http://www.jwz.org/              about:jwz

Date: Wed, 19 Aug 1998 12:16:44 -0700
From: Jamie Zawinski <[email-masked]>
Organization: the mystic knights of mozilla, http://www.mozilla.org/
To: Ned Freed <[email-masked]>
CC: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Ned Freed wrote:
> 
> Its been at least 10 years since these issues arose but it seems like nothing
> has changed. These issues have also surfaced of late in regards to security
> multiparts in the USEFOR WG. (I think a different response is indicated there,
> BTW, but I don't want to get into that here.)

I would suggest that this is in large part because until 2 or 3 years
ago, these were non-problems, and nobody cared.  Nobody really tried to
exchange messages more complex than text/plain in a big way until quite
recently.  Yes, MIME has been around forever, but it only started making
an impact in the real world quite recently.

So I don't think the fact that it has been ten years really says much
about this particular problem; there were other factors.

-- 
Jamie Zawinski             http://www.jwz.org/              about:jwz

Date: Wed, 19 Aug 1998 11:43:02 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
To: Laurence Lundblade <[email-masked]>
Cc: Keith Moore <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

> > So tell me, if one assumes the label approach (which I believe is present
> > in either proposal), why does that label have to be outside the content
> > itself?  What's the difference, really, between a label and an HTML tag?

> Because people get mad at MUA vendors when they see markup crud in their
> mail messages. Same situation as QP encoding.

> It's true that all proposals have some form of labeling. The MIME parameter
> labeling is much more innocuous than a MIME type. Recall my experiment
> where many MUA's failed miserably when presented with a text/paragraph
> entity (even though failing so is a violation of the MIME spec).

Another way to look at this is that we have an installed base to deal with that
has certain features we can count on and certain features we cannot count on.

We can count on facilities to limit display of labels in headers. Headers
have been with us for a very long time and facilities exist in almost
every MUA out there to limit their display.

We cannot count on facilities to limit display of tags embedded in the actual
message text. It is true that MUAs haven't done their best to limit their use
of tags, but it is also true that the tolerance for tags in text is extremely
low.

Similarly, we cannot at this time deploy a new subtype of text without
problems. MIME implementations don't handle this sort of thing very well, the
MIME specification's requirements in this area notwithstanding.

Its been at least 10 years since these issues arose but it seems like nothing
has changed. These issues have also surfaced of late in regards to security
multiparts in the USEFOR WG. (I think a different response is indicated there,
BTW, but I don't want to get into that here.)

				Ned

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, Chris Newman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: format=flowed : why not use HTML? 
Date: Wed, 19 Aug 1998 14:49:53 -0400
Sender: [email-masked]

> >> Are you proposing the use of a profile of HTML, which requires the <html>
> >> prefix and permits only the use of the <p>, <pre> and <br> tags?
> >
> >something like that.  maybe without the <html> prefix.
> 
> But with the quoting convention for "<", ">", and quotation marks.

Yep.

> As Ned is so fond of saying, "That dog don't hunt." 

I thought that was Jeff Case's saying...

> Text/enriched is
> probably more widely deployed in mail programs than text/html, it has a
> much simpler syntax (only "<<" for quoting the "<" symbol and "<nofill>"
> for doing forced-wrap text), and still people wouldn't accept it, let alone
> generate it reasonably. I think using any kind of internal markup that is
> not fully text/plain compatible is a losing battle.

Okay, so this really is the quoted-printable problem all over again.
People won't generate that reasonably either...though I've always
wondered if this is because it seems too difficult, or they haven't
tried, or they didn't think of it, or they just don't care.

Keith

Date: Wed, 19 Aug 1998 13:47:07 -0500
To: Jamie Zawinski <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: [email-masked]
Sender: [email-masked]

On 8/19/98 at 11:36 AM -0700, Jamie Zawinski wrote:

>> Text/enriched is much more widely deployed [...] than HTML.
>
>On what do you base this assertion?  I'm afraid I don't believe it.

You guys support it. We do. Pine does. Anyone with a metamail-compatible
mail reader supports it. Lots of old MIME-aware mailers support it. AOL
doesn't royally screw it up anymore; I don't know how strong their support
for it is.

Seems pretty widely deployed to me. (On the receiving end we're talking
about, not the sending end.)

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

Date: Wed, 19 Aug 1998 13:44:47 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Chris Newman <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

On 8/19/98 at 2:29 PM -0400, Keith Moore wrote:

>> Are you proposing the use of a profile of HTML, which requires the <html>
>> prefix and permits only the use of the <p>, <pre> and <br> tags?
>
>something like that.  maybe without the <html> prefix.

But with the quoting convention for "<", ">", and quotation marks.

>and maybe not an enforced profile, just a set of conventions for
>generating recipient-friendly HTML (instead of multipart/alternative)
>
>We could encourage senders to stay within the recipient-friendly subset,
>and encourage readers to be able to render the recipient-friendly subset
>even if they can't do full HTML.

As Ned is so fond of saying, "That dog don't hunt." Text/enriched is
probably more widely deployed in mail programs than text/html, it has a
much simpler syntax (only "<<" for quoting the "<" symbol and "<nofill>"
for doing forced-wrap text), and still people wouldn't accept it, let alone
generate it reasonably. I think using any kind of internal markup that is
not fully text/plain compatible is a losing battle.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

Date: Wed, 19 Aug 1998 11:43:11 -0700
To: Ian Bell <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: [email-masked]
Sender: [email-masked]

At 3:32 PM +0100 8/14/98, Ian Bell wrote:
>
>There are actually two sorts of lines that are not terminated by "soft"
>line endings: those that form the last lines of paragraphs and those
>that are not intended to be wrapped at all. The distinction is vital but
>this draft seems to confuse the two.

I think in practice we rarely care about this. Simple edit controls don't
allow you to tell the difference between these two cases. You could use a
heuristic that counts spaces and decide it's a table if there's multiple
occurances of multiple spaces, but if you care that much you probably ought
to use HTML.

However the solution is to generate different MIME parts for flowed and
non-flowed text. I'm not sure how often this will be done in practice, but
I feel this is a completely viable option.

I would suggest that the draft say that all line breaks are ends-of-flows
or ends-of-paragraphs and all text is candidate for wrapping. If you want
no wrapping (when possible) you should put it in a different MIME entity.

We should also say in the draft that long "words" (runs with no spaces) are
allowed and should be formatted as best as possible by the receiver.

LL

Date: Wed, 19 Aug 1998 11:36:47 -0700
From: Jamie Zawinski <[email-masked]>
Organization: the mystic knights of mozilla, http://www.mozilla.org/
To: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Pete Resnick wrote:
> 
> Text/enriched is much more widely deployed [...] than HTML. 

On what do you base this assertion?  I'm afraid I don't believe it.

-- 
Jamie Zawinski             http://www.jwz.org/              about:jwz

From: Keith Moore <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: format=flowed : why not use HTML? 
Date: Wed, 19 Aug 1998 14:29:53 -0400
Sender: [email-masked]

> Are you proposing the use of a profile of HTML, which requires the <html>
> prefix and permits only the use of the <p>, <pre> and <br> tags?

something like that.  maybe without the <html> prefix.

and maybe not an enforced profile, just a set of conventions for
generating recipient-friendly HTML (instead of multipart/alternative)

We could encourage senders to stay within the recipient-friendly subset,
and encourage readers to be able to render the recipient-friendly subset
even if they can't do full HTML.

> That's equivalent to creating a new markup language in my book, something
> which I believe would be even less successful than text/enriched.  

Given that HTML is already supported by a large number of user agents, 
I'm not sure why this should be the case.

> One certainly can't re-use the text/html label for such a profile as there 
> are deployed clients which deliberately don't display text/html to the user
> because it's almost always unreadable (I'm using one such client).

Surely this is configurable?

The impression I'm getting is that HTML has suffered from what I think
of as "ASN.1 disease" (though it could equally apply to a number of other
things):  If a technology has a lot more features than is needed to do a
particular job, those features get used whether they're needed or not.  
The results tend to be so ugly that people are biased against any use 
of the technology, even when such use is reasonable and appropriate.

Keith

Date: Wed, 19 Aug 1998 10:50:03 -0700
To: Keith Moore <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Chris Newman <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

At 1:36 PM -0400 8/19/98, Keith Moore wrote:
>
>So tell me, if one assumes the label approach (which I believe is present
>in either proposal), why does that label have to be outside the content
>itself?  What's the difference, really, between a label and an HTML tag?
>

Because people get mad at MUA vendors when they see markup crud in their
mail messages. Same situation as QP encoding.

It's true that all proposals have some form of labeling. The MIME parameter
labeling is much more innocuous than a MIME type. Recall my experiment
where many MUA's failed miserably when presented with a text/paragraph
entity (even though failing so is a violation of the MIME spec).

LL

Date: Wed, 19 Aug 1998 11:03:03 -0700
To: Chris Newman <[email-masked]>, Keith Moore <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: [email-masked]
Sender: [email-masked]

At 10:26 AM -0700 8/19/98, Chris Newman wrote:

>There are only two ways to solve this problem -- create a label to
>distinguish (A) from (B), or create a way to encode the functionality of
>(B) such that it is 100% compatible with (A).  I proposed the former with
>text/paragraph and Randy has proposed the latter.

The problem with text/paragraph is that in tests many mailers treated
it as an attachment, which made it difficult to use.

Date: Wed, 19 Aug 1998 11:00:29 -0700
To: Ian Bell <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

At 9:34 AM +0100 8/19/98, Ian Bell wrote:

>If format=flowed used text/enriched-like line conventions (one CRLF =>
>soft eol, n CRLFs => n-1 hard eols) rather than trailing spaces, would
>a consensus be reached?

But that is not backwards compatible with text/plain.

The advantage of Format=Flowed is that is it very simple, and fully
compatible with text/plain.

Date: Wed, 19 Aug 1998 11:04:30 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Wed, 19 Aug 1998, Keith Moore wrote:
> So tell me, if one assumes the label approach (which I believe is present
> in either proposal), why does that label have to be outside the content
> itself?

Because if it's in the content, then recipients will see it and assume
something is broken.

>  What's the difference, really, between a label and an HTML tag?

Are you proposing the use of a profile of HTML, which requires the <html>
prefix and permits only the use of the <p>, <pre> and <br> tags?

That's equivalent to creating a new markup language in my book, something
which I believe would be even less successful than text/enriched.  One
certainly can't re-use the text/html label for such a profile as there are
deployed clients which deliberately don't display text/html to the user
because it's almost always unreadable (I'm using one such client).

		- Chris

Date: Wed, 19 Aug 1998 13:01:45 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Chris Newman <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

On 8/19/98 at 1:36 PM -0400, Keith Moore wrote:

>So tell me, if one assumes the label approach (which I believe is present
>in either proposal), why does that label have to be outside the content
>itself?  What's the difference, really, between a label and an HTML tag?

Because things labeled as text/plain do not have interpreable content.
Text/html and text/enriched have guarantees about what will and will not be
displayed to the user. Whatever label we choose inside text/plain is by
definition legal to have in a text/plain message without it being
meaningful as a label.

Text/enriched is much more widely deployed and much easier to send without
gobs of markup than HTML. But as Ned points out, none of the promises have
borne fruit. I think this is a perfectly reasonable solution to a problem
that's been empirically shown not to be solveable by choosing a different
content-type.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102

Date: Wed, 19 Aug 1998 10:50:28 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: draft-gellens-format-00
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Wed, 19 Aug 1998, Ian Bell wrote:
> If format=flowed used text/enriched-like line conventions (one CRLF =>
> soft eol, n CRLFs => n-1 hard eols) rather than trailing spaces, would
> a consensus be reached? (I have already suggested this to Randy.)

No.  That would force things which generate tables and the like to
double-space them so they'd be ugly to currently compliant text/plain
engines.

The goal is to not break currently compliant text/plain engines, while at
the same time providing a legitimate way for currently incompliant clients
to generate flowable paragraphs in text/plain.

I really see two alternate proposals at this point:

(1) Randy's format=flowed proposal -- a largely backwards compatible
modification to text/plain. 

(2) A "format=paragraph/lines" label for paragraph-oriented text --
backwards compatible with current use, but not with current standards. 

		- Chris

From: Keith Moore <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: format=flowed : why not use HTML? 
Date: Wed, 19 Aug 1998 13:36:59 -0400
Sender: [email-masked]

> > I don't understand why we need yet another tweak to handle the
> > special case of text without line breaks.  Why not just use 
> > "recipient friendly HTML" for such cases?   Especially since 
> > it's already supported (for reading, anyway) by most user agents.
> 
> The issue has nothing to do with markup languages. The issue is to fix an
> interoperability problem with text/plain as follows:
> 
> We can deploy 100 different uses of markup languages and it won't change
> this problem.
[...] 
> There are only two ways to solve this problem -- create a label to
> distinguish (A) from (B), or create a way to encode the functionality of
> (B) such that it is 100% compatible with (A).  I proposed the former with
> text/paragraph and Randy has proposed the latter.

So tell me, if one assumes the label approach (which I believe is present
in either proposal), why does that label have to be outside the content
itself?  What's the difference, really, between a label and an HTML tag?

Keith

Date: Wed, 19 Aug 1998 10:26:33 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Tue, 18 Aug 1998, Keith Moore wrote:
> I don't understand why we need yet another tweak to handle the
> special case of text without line breaks.  Why not just use 
> "recipient friendly HTML" for such cases?   Especially since 
> it's already supported (for reading, anyway) by most user agents.

The issue has nothing to do with markup languages. The issue is to fix an
interoperability problem with text/plain as follows:

(A) some text/plain is generated to be displayed in fixed-width with hard
line breaks.  This is used for tables.  In fact, I get my monthly
long-distance phone bill by email in this format (160 columns).

(B) some text/plain is generated in paragraph form with the intent that it
will be wrapped by the recipient.

(C) Wrapping (A) will break it severely -- it really needs to be displayed
fixed width with a horizontal scroll bar if necessary.

(D) Displaying (B) without wrapping will break it -- if it's displayed
with a horizontal scroll bar, it is largely unreadable.

(E) There is no way to distinguish (A) from (B) at the recipient end,
except with heuristics or a manual client option.

We can deploy 100 different uses of markup languages and it won't change
this problem.

There are only two ways to solve this problem -- create a label to
distinguish (A) from (B), or create a way to encode the functionality of
(B) such that it is 100% compatible with (A).  I proposed the former with
text/paragraph and Randy has proposed the latter.

It may be the case that it's just too late to fix the problem and we'll
all have to live with it.  But we should at least seriously evaluate the
proposals.

		- Chris

P.S. There is significant evidence that it's too hard to make SGML-based
markup recipient friendly.

Date: Wed, 19 Aug 1998 09:38:55 -0700
To: [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: Re: why not use *ML (was: format=flowed : why not use HTML?)
Cc: [email-masked] (Jamie Zawinski), [email-masked]
Sender: [email-masked]

I think all the same arguments that apply to HTML, in particular "simple"
HTML, apply here. What we're looking for is backwards compatibility to
plain text that requires no conversion. Also as Ned points out, previous
attempts at "simple" markup have all failed.

LL

At 5:51 AM +0100 8/19/98, Daniel Glazman wrote:
> ...
>I then suggest to skip a step and promote a XML e_mail. We could have
>at least two DTDs : one for plain e_mail with coding white spaces and
>carriage returns (see PRE element in HTML) and another model for
>richer content, one of its elements acting as a PRE. The first one
>will garanty backward compatibility with text/plain. We can also be
>ready to integrate the XMLized version of HTML as soon as the new HTML
>WG of W3C delivers it. Of course, the XML+XSL or XML+CSS browsers that
>the vendors are preparing will have no difficulty to display such
>messages...

> ...

Date: Wed, 19 Aug 1998 09:34:01 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

On Tue, 18 Aug 1998, Ned Freed <[email-masked]> writes
>Ah, the old "if we legalize it everyone will start abusing it" argument. I'm
>sorry, but I don't buy this line of reasoning in the "war on drugs" and
>I don't buy it here.
>

No, I was worried that the very _use_ (not abuse) of these proposals
could cause problems with deployed MUAs.

>Again, I don't especially care what we do as long as we do something and do it
>soon.

It would be worse to do something quickly that broke the installed base
than do nothing at all.

> But what we do needs to be selected not on the basis of "this could be
>abused hence it is bad" sorts of arguments, but instead on the basis of "this
>is more likely to be seen as solving a problem for MUA writers and hence is
>more likely to be deployed". Any of these schemes can and will be abused.

Agreed.

>I can accept an argument along the lines of "this is too complex and either
>won't get implemented or won't get implemented correctly". And I definitely
>think that what you originally proposed is far too complex. Randy's scheme is
>much simpler, but I remain to be convinced it is simple enough. And for that
>matter, I can also accept an argument that "we're unlikely to reach consensus
>on one of these trailing space thingies any time soon so we'd best go with a
>simpler labelling scheme we can reach consensus on".
>

If format=flowed used text/enriched-like line conventions (one CRLF =>
soft eol, n CRLFs => n-1 hard eols) rather than trailing spaces, would
a consensus be reached? (I have already suggested this to Randy.)

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

From: [email-masked] (Daniel Glazman)
Subject: why not use *ML (was: format=flowed : why not use HTML?)
To: [email-masked] (Jamie Zawinski)
Date: Wed, 19 Aug 1998 05:51:42 +0100 (WET DST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

> Michael A Quinlan wrote:
> > 
> > I would like to vote in favor of this as well. Resources would be
> > better spent improving support for HTML in MUAs instead of coming up
> > with yet another format for flowed text.
> 
> Me too, but for a slightly different reason: history shows that we've
> had enough trouble getting text/plain to be used properly.  By adding a

Oh yes. Some browsers used to add invalid parameters to content-type
and even sometimes to Mime-Version !-)))

I still have in my filesystem some of the mails I exchanged with Ed
Levinson in 1992 when we first discussed SGML transport by
e_mail. Most of the issues have been raised, discussed, solved and
quite nothing has never been implemented.

HTML e_mail is IMO not the solution. HTML is very complex, but in fact
very narrow. HTML is really not made for documents, it is made for
information.

I then suggest to skip a step and promote a XML e_mail. We could have
at least two DTDs : one for plain e_mail with coding white spaces and
carriage returns (see PRE element in HTML) and another model for
richer content, one of its elements acting as a PRE. The first one
will garanty backward compatibility with text/plain. We can also be
ready to integrate the XMLized version of HTML as soon as the new HTML
WG of W3C delivers it. Of course, the XML+XSL or XML+CSS browsers that
the vendors are preparing will have no difficulty to display such
messages...

BTW, I don't want to throw oil in the fire, but a XML DTD for
messages, ***including headers***, could be helpful, very easily
extensible through various mechanisms (new elements, new attributes),
and Unicode. Backward compatibility between XMLmail versions could be
organised using public XSL tree transformation rules.

The documentation world went from a GML syntax (very close to RFC822
headers) to SGML and XML (markup languages for structured data), the
wold is ready to use the XML-based products that Microscape is
building, and RFC822 is still RFC822.

This is not a dream at all. I would be very surprised if Jean Paoli @
Microsoft has no such project (or beta1-but-ready-to-ship version ?-)
somewhere in his office. E_mail is a too important part of the
information circulation process that MS wants to rule to be left by
them on the right side of the road..

</Daniel>

Date: Tue, 18 Aug 1998 17:28:21 -0700
To: Keith Moore <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
Cc: Randall Gellens <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

--============_-1308635932==_ma============
Content-Type: text/plain; charset="us-ascii"

I think the main argument here is that HTML is not backwards compatible
with text/plain and text formats used by common OS's. Converting
format=flowed to format=fixed is just a matter of relabeling (or
unlabeling).

One could consider multipart/alternative backwards compatibility of sorts,
but it's just not the same. It requires MIME structure to work where
format=flowed doesn't.

Also, I don't think we're ready to say that all text on the Internet ought
to be HTML. HTML is just too difficult to display, search edit, etc. If we
had simple HTML editors standard with OS's and tools like grep that were
HTML aware it would be worth considering.

We can almost say all text on the Internet is compatible with format=flowed
because it is basically a nil operation to convert it to the text formats
used in e-mail and elsewhere.

LL

At 6:07 PM -0400 8/18/98, Keith Moore wrote:
>I don't understand why we need yet another tweak to handle the special
>case of text without line breaks. Why not just use "recipient friendly
>HTML" for such cases? Especially since it's already supported (for
>reading, anyway) by most user agents.
>
>HTML doesn't have to be ugly, and it doesn't have to mess up replies.
>
>Keith

--============_-1308635932==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: format=flowed : why not use
HTML?</title></head><body>
<div>I think the main argument here is that HTML is not backwards
compatible with text/plain and text formats used by common OS's.
Converting format=flowed to format=fixed is just a matter of
relabeling (or unlabeling).</div>
<div><br></div>
<div>One could consider multipart/alternative backwards compatibility
of sorts, but it's just not the same. It requires MIME structure to
work where format=flowed doesn't.</div>
<div><br></div>
<div>Also, I don't think we're ready to say that all text on the
Internet ought to be HTML. HTML is just too difficult to display,
search edit, etc. If we had <i>simple</i> HTML editors standard with
OS's and tools like grep that were HTML aware it would be worth
considering.</div>
<div><br></div>
<div>We can almost say all text on the Internet is compatible with
format=flowed because it is basically a nil operation to convert it
to the text formats used in e-mail and elsewhere.</div>
<div><br></div>
<div>LL</div>
<div><br></div>
<div><br></div>
<div>At 6:07 PM -0400 8/18/98, Keith Moore wrote:</div>
<blockquote type="cite" cite>I don't understand why we need yet
another tweak to handle the special case of text without line breaks.
Why not just use &quot;recipient friendly HTML&quot; for such cases?
Especially since it's already supported (for reading, anyway) by most
user agents.</blockquote>
<blockquote type="cite" cite><br>
HTML doesn't have to be ugly, and it doesn't have to mess up
replies.</blockquote>
<blockquote type="cite" cite><br>
Keith</blockquote>
<div><br></div>
</body>
</html>
--============_-1308635932==_ma============--

Date: Tue, 18 Aug 1998 17:13:10 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: format=flowed : why not use HTML?
To: Keith Moore <[email-masked]>
Cc: Randall Gellens <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> I don't understand why we need yet another tweak to handle the
> special case of text without line breaks.  Why not just use
> "recipient friendly HTML" for such cases?   Especially since
> it's already supported (for reading, anyway) by most user agents.

> HTML doesn't have to be ugly, and it doesn't have to mess up
> replies.

We've been waiting for someone to deliver on this promise for almost 8 years
now. It hasn't happened yet. The agents that generate HTML, or enriched, or
richtext, have without exception produced material that simply is not
acceptably simple. At least two of these formats were specifically designed for
this use and it hasn't helped.

And in the meantime the erosion of what text/plain means and is useful for
continues. We haven't even slowed it down.

I'm sorry, but unless you can offer something more concrete than a suggestion
as to how things could be done I'm afraid I have to classify this as simply
wishful thinking on your part.

				Ned

Date: Tue, 18 Aug 1998 16:18:44 -0700
From: Jamie Zawinski <[email-masked]>
Organization: the mystic knights of mozilla, http://www.mozilla.org/
To: [email-masked]
Subject: Re: format=flowed : why not use HTML?
Sender: [email-masked]

Michael A Quinlan wrote:
> 
> I would like to vote in favor of this as well. Resources would be
> better spent improving support for HTML in MUAs instead of coming up
> with yet another format for flowed text.

Me too, but for a slightly different reason: history shows that we've
had enough trouble getting text/plain to be used properly.  By adding a
new variant of (or parameter to) text/plain, we're only going to make
things more complicated, and thereby make that problem harder, not
easier.

I say leave bad enough alone, and use other content-types for future
advances.

-- 
Jamie Zawinski             http://www.jwz.org/              about:jwz

Reply-To: <[email-masked]>
From: "Michael A Quinlan" <[email-masked]>
To: "Randall Gellens" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: format=flowed : why not use HTML?
Date: Tue, 18 Aug 1998 16:54:45 -0600
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01BDCAC8.E7100A60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I would like to vote in favor of this as well. Resources would be better
spent improving support for HTML in MUAs instead of coming up with yet
another format for flowed text.
    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]On Behalf Of
Keith Moore
    Sent: Tuesday, August 18, 1998 4:08 PM
    To: Randall Gellens
    Cc: [email-masked]; [email-masked]
    Subject: format=flowed : why not use HTML?

    I don't understand why we need yet another tweak to handle the special
case of text without line breaks. Why not just use "recipient friendly HTML"
for such cases? Especially since it's already supported (for reading,
anyway) by most user agents.

    HTML doesn't have to be ugly, and it doesn't have to mess up replies.

    Keith

------=_NextPart_000_000D_01BDCAC8.E7100A60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY>
<DIV>
<DIV><SPAN class=3D820504722-18081998><FONT size=3D3><FONT =
face=3DArial><FONT=20
color=3D#000000>I would like to vote in favor of this as well. Resources =
would be=20
better spent improving support for HTML in MUAs instead of coming up =
with yet=20
another format for flowed text.</FONT></FONT></FONT></SPAN><FONT=20
color=3D#000000><FONT face=3DArial><FONT =
size=3D3></FONT></FONT></FONT></DIV></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
    size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
    [mailto:[email-masked]]<B>On Behalf Of</B> Keith=20
    Moore<BR><B>Sent:</B> Tuesday, August 18, 1998 4:08 PM<BR><B>To:</B> =
Randall=20
    Gellens<BR><B>Cc:</B> [email-masked]; =
[email-masked]<BR><B>Subject:</B>=20
    format=3Dflowed : why not use HTML?<BR><BR></FONT></DIV>
    <P>I don't understand why we need yet another tweak to handle the =
special=20
    case of text without line breaks. Why not just use &quot;recipient =
friendly=20
    HTML&quot; for such cases? Especially since it's already supported =
(for=20
    reading, anyway) by most user agents.=20
    <P>HTML doesn't have to be ugly, and it doesn't have to mess up =
replies.=20
    <P>Keith </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000D_01BDCAC8.E7100A60--

From: Keith Moore <[email-masked]>
To: Randall Gellens <[email-masked]>
cc: [email-masked], [email-masked]
Subject: format=flowed : why not use HTML?
Date: Tue, 18 Aug 1998 18:07:56 -0400
Sender: [email-masked]

<html>
<p>
I don't understand why we need yet another tweak to handle the
special case of text without line breaks.  Why not just use 
"recipient friendly HTML" for such cases?   Especially since 
it's already supported (for reading, anyway) by most user agents.
<p>
HTML doesn't have to be ugly, and it doesn't have to mess up
replies.
<p>
Keith
</html>

Date: Tue, 18 Aug 1998 11:57:10 -0700
To: Ian Bell <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

At 2:18 AM -0700 8/18/98, Ian Bell wrote:

>Paragraph-oriented text is restricted at the moment to non-compliant
>MUAs abusing text/plain. As soon as there is a standard way of labelling
>paragraph text, it will probably become much more common. Promotion of
>format=flowed to format=fixed will then lead to broken display/reply
>as in:
>
>
>> : ian: randy> } This paragraph has been quoted five times using
>>quoting conventions often seen. How will you display it correctly,
>>let alone reply and quote correctly: especially if the user wants to
>>split the paragraph in two?

Converting Format=flowed to Format=fixed is no problem, because the
lines are already wrapped and canonically quoted.

Converting Format=fixed to Format=Flowed is a different matter.  It's
hard to do,  but no worse than reformatting normal text/plain, which is
what happens now.

Date: Tue, 18 Aug 1998 11:19:55 -0700
To: Ned Freed <[email-masked]>, Ian Bell <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Cc: [email-masked]
Sender: [email-masked]

At 8:28 AM -0700 8/18/98, Ned Freed wrote:

>As for the example you cite, where quoting appears at the beginning of a long
>line, I already see it on a regular basis. I'd even say it is fast becoming a
>defacto standard way of quoting. In fact what I now see on a regular basis is
>the sort of quoting I deliberately used above. And to the extent that
>_any_ of
>these proposals legitimize flowed text, I see them making this sort of
>quoting
>more common. Perhaps I'm missing something, but I don't see this particular
>proposal as especially bad in this regard. But I'm prepared to live with some
>damage to quoting in the short term if we get a better result in the
>long term,
>especially since I believe damage to quoting scheme in the short term is
>inevitable no matter what we do (or don't do).

The draft says that each line of a quoted flowed paragraph must be
quoted with the canonical quote indicator (">" or "> ").  It can
therefore be treated as normal text/plain by older agents, or as quoted
flowed by newer ones, in either case being better than what we have
now.  So it seems to me that the proposal (if adopted) would make the
problem better, not worse.

Date: Tue, 18 Aug 1998 11:21:59 -0700
To: Ian Bell <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

At 2:18 AM -0700 8/18/98, Ian Bell wrote:

>Paragraph-oriented text is restricted at the moment to non-compliant
>MUAs abusing text/plain. As soon as there is a standard way of labelling
>paragraph text, it will probably become much more common. Promotion of
>format=flowed to format=fixed will then lead to broken display/reply
>as in:
>
>
>> : ian: randy> } This paragraph has been quoted five times using
>>quoting conventions often seen. How will you display it correctly,
>>let alone reply and quote correctly: especially if the user wants to
>>split the paragraph in two?

Format=flowed quoted text must be quoted using the canonical quote
indicator, so the problem is better.  Promotion of Format=fixed to
Format=flowed can be tricky, but is no worse than the status quo, and
if agents start generating Format=flowed will be less common.

Date: Tue, 18 Aug 1998 08:28:05 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: draft-gellens-format-00
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII

> > However, I fail to see what this has to do with the present proposal. Yes,
if you do promotion to flowed text willy-nilly you can have trouble. But this
is already happening -- lots of deployed agents do this sort of promotion
routinely, and it isn't going to stop no matter what the standards say.

> Paragraph-oriented text is restricted at the moment to non-compliant MUAs
abusing text/plain. As soon as there is a standard way of labelling paragraph
text, it will probably become much more common. Promotion of format=flowed to
format=fixed will then lead to broken display/reply as in:

Ah, the old "if we legalize it everyone will start abusing it" argument. I'm
sorry, but I don't buy this line of reasoning in the "war on drugs" and
I don't buy it here.

The reality is that non-compliant MUAs are already _very_ common, and they
aren't going away no matter how loudly we shout standards violation. And as a
direct consequence of this even compliant MUAs find it necessary to reformat
text all the time. They don't have a choice. So the net result is that it is
increasingly difficult to get formatted text to stay formatted. I now have
trouble with this on a daily basis and it gets worse all the time.

Again, I don't especially care what we do as long as we do something and do it
soon. But what we do needs to be selected not on the basis of "this could be
abused hence it is bad" sorts of arguments, but instead on the basis of "this
is more likely to be seen as solving a problem for MUA writers and hence is
more likely to be deployed". Any of these schemes can and will be abused.

I can accept an argument along the lines of "this is too complex and either
won't get implemented or won't get implemented correctly". And I definitely
think that what you originally proposed is far too complex. Randy's scheme is
much simpler, but I remain to be convinced it is simple enough. And for that
matter, I can also accept an argument that "we're unlikely to reach consensus
on one of these trailing space thingies any time soon so we'd best go with a
simpler labelling scheme we can reach consensus on".

As for the example you cite, where quoting appears at the beginning of a long
line, I already see it on a regular basis. I'd even say it is fast becoming a
defacto standard way of quoting. In fact what I now see on a regular basis is
the sort of quoting I deliberately used above. And to the extent that _any_ of
these proposals legitimize flowed text, I see them making this sort of quoting
more common. Perhaps I'm missing something, but I don't see this particular
proposal as especially bad in this regard. But I'm prepared to live with some
damage to quoting in the short term if we get a better result in the long term,
especially since I believe damage to quoting scheme in the short term is
inevitable no matter what we do (or don't do).

				Ned

Date: Tue, 18 Aug 1998 16:45:28 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

On Tue, 18 Aug 1998, [email-masked] writes
>On Tue, 18 Aug 1998 10:18:22 BST, you said:
>> I don't see how that poses a problem at all - it is entirely a matter
>> for the user. If they want to send preformatted material, they will have
>> to send unflowed text (presuming all MUAs give a choice between flowed
>> and unflowed text).
>
>That's a very big presumption. I'm still stumbling once in a while
>across old MUAs that don't understand that unknown multipart/frobozz
>should be treated as /mixed, or can't get quoted-printable right (most
>often, quoting but leaving the CTE blank).
>

Sorry, I actually meant "(presuming that all MUAs that implement the
new standard for flowed text give a choice between flowed and unflowed
text)" - a very different presumption! I think my point is still valid
(but I'm no longer so sure!).

>> However, if this sort of quoting problem is not considered important, I
>> would much rather see the original idea of text/paragraph or
>
>Personally, I call it more than "important".  I consider *any*
>proposal that doesn't allow for sane quoting/attribution as being
>terminally broken on the show-stopper level.
>
>Yes, I know currently quoting/citing is a mess.  However, this is in
>the category of legacy systems.  Any *new* proposal has to do better
>and not present new challenges to the authors of MUAs.
>

Which is absolutely where I stand. When discussing text/paragraph
months back, I said:

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

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

To: Ian Bell <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-gellens-format-00 
From: [email-masked]
Date: Tue, 18 Aug 1998 10:13:40 -0400
Sender: [email-masked]

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

On Tue, 18 Aug 1998 10:18:22 BST, you said:
> I don't see how that poses a problem at all - it is entirely a matter
> for the user. If they want to send preformatted material, they will have
> to send unflowed text (presuming all MUAs give a choice between flowed
> and unflowed text).

That's a very big presumption. I'm still stumbling once in a while
across old MUAs that don't understand that unknown multipart/frobozz
should be treated as /mixed, or can't get quoted-printable right (most
often, quoting but leaving the CTE blank).

What happens when an older MUA is passed one of these flowed/unflowed
creations?

> However, if this sort of quoting problem is not considered important, I
> would much rather see the original idea of text/paragraph or

Personally, I call it more than "important".  I consider *any*
proposal that doesn't allow for sane quoting/attribution as being
terminally broken on the show-stopper level.

Yes, I know currently quoting/citing is a mess.  However, this is in
the category of legacy systems.  Any *new* proposal has to do better
and not present new challenges to the authors of MUAs.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

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

--==_Exmh_-863234108P--

Date: Tue, 18 Aug 1998 10:18:22 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

Hand-built MIME - any mistakes are my fault!

---
Content-Type: text/plain;format=fixed

On Mon, 17 Aug 1998, Ned Freed <[email-masked]> writes
>> > > If there is no way to tag a line as "don't wrap this", replies to
>> > > standard text/plain messages MUST NOT be promoted to format=flowed
>
>> > Promotion to format=flowed should be done with care, and probably only
>> > under user direction, as I see it.  It's the safest course.
>
>> Users won't be aware of the problems of promoting to format-flowed -
>> they will probably always do it so that their own text will look pretty.
>> The result will be that quoted text will get miss-attributed whenever
>> any non-standard quote character has been used.
>
>This is but one of many potential problems. FWIW, the one that bothers me the
>most is that preformatted material such as tables can get damaged.
>Specifically, a user may see something that looks OK when they display it due
>to their choice of widths. But when they resend it labelled as flowed it
>subsequently gets ruined.
>

I don't see how that poses a problem at all - it is entirely a matter
for the user. If they want to send preformatted material, they will have
to send unflowed text (presuming all MUAs give a choice between flowed
and unflowed text).

>However, I fail to see what this has to do with the present proposal. Yes, if
>you do promotion to flowed text willy-nilly you can have trouble. But this is
>already happening -- lots of deployed agents do this sort of promotion
>routinely, and it isn't going to stop no matter what the standards say.
>

Paragraph-oriented text is restricted at the moment to non-compliant
MUAs abusing text/plain. As soon as there is a standard way of labelling
paragraph text, it will probably become much more common. Promotion of
format=flowed to format=fixed will then lead to broken display/reply
as in:

---
Content-Type: text/plain;format=flowed

> : ian: randy> } This paragraph has been quoted five times using quoting conventions often seen. How will you display it correctly, let alone reply and quote correctly: especially if the user wants to split the paragraph in two?

---
Content-Type: text/plain;format=fixed

The problem of quoted text being badly displayed and badly requoted will
have become a consequence of a published standard rather than the
consequence of a non-conformant MUA breaking text/plain - much worse IMO.

However, if this sort of quoting problem is not considered important, I
would much rather see the original idea of text/paragraph or
format=flowed as a simple label for paragraph oriented text rather
than any line-ending encoding scheme (the problem is actually less severe
in a labelling scheme).

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

-----

Date: Mon, 17 Aug 1998 22:26:24 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: 8BITMIME to 7BIT
To: Jacob Palme <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> At 20.33 +0200 98-08-17, Ned Freed wrote:
> > Received: fields, like Resent- fields are only added to primary message
> > headers, which existing email signature mechanisms do not cover.

> Does that mean that existing signature standards will not
> guarantee that the subject or the CC fields have not been
> tampered with?

It depends on which fields you are talking about. If you are talking about
fields at the outermost level, then yes, existing signature standards have no
way to sign them. However, there is nothing to prevent you from using an extra
wrapper around the actual message if you want to secure these fields. You can
even wrap up the entire SMTP transaction if you like and tunnel it through
inside a message.

> Is that acceptable?

It certainly appears to be.

> And how about the date,
> that could have legal significance in some cases, why
> should it not be protected?

The date claimed by the message originator has little if any significance in
most cases. What would matter would be, say, a date added by a timestamping
service. But in such cases encapsulation of the message along with timestamp
information is essential. And existing signature protocols handle this just
fine modulo a somewhat more specialized timestamp container specification --
the tricky part is the timestamp service and the liability issues it faces.

> Also the From and and the
> In-Reply-To fields can be quite significant. The intrinsic
> meaning of a message with the text "Yes, I agree" can be
> quite different depending on the value of the In-Reply-To
> header.

Again, the From: address claimed by the originator is of little signifcance.
And similarly, for the in-reply-to to have tamper-proof meaning imposes
requirements not only on the in-reply-to field but also on what it refers to.
You can build systems that secure this sort of thing using existing protocols,
but it remains to be seen whether anybody thinks it important enough to
actually do so.

Jacob, all of these points and literally hundreds of others have been discussed
ad nauseum in the development of PEM, MSP, security multiparts, MOSS, S/MIME,
PGP-MIME, and OpenPGP. We're talking 10+ years of standards work and heaven
only knows how many messages -- hundreds of thousands at a minimum. I suggest
you review the (vast) record in this area. This is neither the time nor the
place to discuss these matters.

				Ned

Date: Tue, 18 Aug 1998 02:54:15 +0200
To: Ned Freed <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: 8BITMIME to 7BIT
Cc: [email-masked]
Sender: [email-masked]

At 20.33 +0200 98-08-17, Ned Freed wrote:
> Received: fields, like Resent- fields are only added to primary message
> headers, which existing email signature mechanisms do not cover.

Does that mean that existing signature standards will not
guarantee that the subject or the CC fields have not been
tampered with? Is that acceptable? And how about the date,
that could have legal significance in some cases, why
should it not be protected? Also the From and and the
In-Reply-To fields can be quite significant. The intrinsic
meaning of a message with the text "Yes, I agree" can be
quite different depending on the value of the In-Reply-To
header.
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Mon, 17 Aug 1998 11:33:29 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: 8BITMIME to 7BIT
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> The idea to define a way of computing security and identity
> hash sums which will be the same with certain common
> conversions which might occur on a message is great if you
> can make it work. In addition to 8BIT to 7BIT or the
> reverse, are there other things which should be canonized?
> How about trailing spaces in lines? How about inserting
> line breaks into lines longer than 80 chars? How about
> addition of certain headers, like "Resent-" and "Received:"?

I'm afraid  this is precisely why we didn't define such a hashing scheme
initially -- once you start down this path people come up with ratholes such as
these. 

The problem with trailing spaces on lines is that they may have significant
meaning attached to them. It is axiomatic in security systems that you cannot
exclude from a hash things that can have significant meaning.

Igoring/adding line breaks is, if anything, far worse. If you want to monkey
with this sort of stuff do it before the signature is added.

As for the addition of headers, this would only be meaningful/useful if people
inserted this sort of stuff into signed heades. In practice they do not -- such
fields are attached to the primary message header, which for many reasons
cannot be signed reliably.

> The people who define security stuff, have they not already
> defined some of this?

No, for the simple reason that doing so is a very bad idea.

Even rigidly structured formats like ASN.1 encodings have all sorts of
canonicalization problems in practice. And text formats are much, much
worse.

> At least the addition of "Received:"
> headers ought to be in the methods already. Or perhaps they
> compute a checksum only on the content, not on the RFC 822
> heading?

> Received: fields, like Resent- fields are only added to primary message
headers, which existing email signature mechanisms do not cover.

				Ned

Date: Mon, 17 Aug 1998 19:29:44 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: 8BITMIME to 7BIT
Sender: [email-masked]

The idea to define a way of computing security and identity
hash sums which will be the same with certain common
conversions which might occur on a message is great if you
can make it work. In addition to 8BIT to 7BIT or the
reverse, are there other things which should be canonized?
How about trailing spaces in lines? How about inserting
line breaks into lines longer than 80 chars? How about
addition of certain headers, like "Resent-" and "Received:"?

The people who define security stuff, have they not already
defined some of this? At least the addition of "Received:"
headers ought to be in the methods already. Or perhaps they
compute a checksum only on the content, not on the RFC 822
heading?
------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Mon, 17 Aug 1998 08:33:53 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: draft-gellens-format-00
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > If there is no way to tag a line as "don't wrap this", replies to
> > > standard text/plain messages MUST NOT be promoted to format=flowed

> > Promotion to format=flowed should be done with care, and probably only
> > under user direction, as I see it.  It's the safest course.

> Users won't be aware of the problems of promoting to format-flowed -
> they will probably always do it so that their own text will look pretty.
> The result will be that quoted text will get miss-attributed whenever
> any non-standard quote character has been used.

This is but one of many potential problems. FWIW, the one that bothers me the
most is that preformatted material such as tables can get damaged.
Specifically, a user may see something that looks OK when they display it due
to their choice of widths. But when they resend it labelled as flowed it
subsequently gets ruined.

However, I fail to see what this has to do with the present proposal. Yes, if
you do promotion to flowed text willy-nilly you can have trouble. But this is
already happening -- lots of deployed agents do this sort of promotion
routinely, and it isn't going to stop no matter what the standards say.

The most we can hope for is that agents will adopt a proposal that to some
extent legitimizes what they are doing. And it would help enormously to have a
means of labelling flowed text for what it is. And frankly, I no longer
particularly care what form the labelling takes -- the longer we continue to
debate this in our quest for the optimal format and label, the harder it is
going to be to get something deployed. In fact it may already be too late.

The thing I don't like about this proposal is that it asks for a change of
behavior in text generation. Having a way to label flowed text for what it is
seems reasonable and it seems like something agents could adopt fairly readily.
But placing more elaborate requirements on what they generate and how they
interpret what they receive seems risky to me -- will agents actually do this,
or have we raised the bar too high?

Now, I'm willing to be told by the MUA folks that this proposal, if adopted,
will get them to change their ways. But I'd really like to hear this stated
directly.

				Ned

Date: Fri, 17 Jul 1998 15:25:58 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

On Fri, 14 Aug 1998, Randall Gellens <[email-masked]> writes
>At 7:32 AM -0700 8/14/98, Ian Bell wrote:
>

>>If there is no way to tag a line as "don't wrap this", replies to
>>standard text/plain messages MUST NOT be promoted to format=flowed
>
>Promotion to format=flowed should be done with care, and probably only
>under user direction, as I see it.  It's the safest course.
>

Users won't be aware of the problems of promoting to format-flowed -
they will probably always do it so that their own text will look pretty.
The result will be that quoted text will get miss-attributed whenever
any non-standard quote character has been used.

>>Comments were solicited as to the UseNet signature convention. 
>
>Many people generate it, but does anyone care about it on reception?
>

Yes! It seems to me that the major purpose of using a standard sig-
separator is that receiving MUAs can strip off the signature when
replies are being prepared. This prevents messages being bloated by
including quoted signatures, or forcing users to snip out signatures by
hand. Not treating "-- " specially may break this.

Overall, I tend to agree with the original consensus that the use of
trailing space is not a good solution to the problem of paragraph-
oriented text. Indeed, most solutions appear to be worse than the
problem itself - heuristics may be applied reasonably successfully to
detect abuse of text/plain, but text/paragraph etc. could irreversibly
break message attribution. 

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

Date: Mon, 17 Aug 1998 09:35:56 +0200
To: Ned Freed <[email-masked]>, Pete Resnick <[email-masked]>
From: Harald Alvestrand <[email-masked]>
Subject: Re: 8BITMIME to 7BIT
Cc: [email-masked]
Sender: [email-masked]

At 14:41 10.07.98 -0700, Ned Freed wrote:
>I think a better way to resolve this problem is to define a different
canonical
>form for use in computing hashes. (The key characteristic of the new form
needs
>to be that the hash of part data is done under the encoding.) This could be
>indicated in the micalg field by a different hash name. I've been meaning to
>write an RFC defining such a thing for quite some time but haven't managed to
>find the time to do so. This is also hard to deploy, but has the added
benefit
>of resolving a different problem, specifically that message stores have to
>store both encoded and decoded parts when handling multipart/signed. Many
>people believe this is a far more serious problem than an occasional
signature
>mismatch caused by poor encoding choices, enough that we might just possibly
>get some buy-in and some resulting deployment of such a mechanism.

by "under the encoding" you mean that the hash is computed across
the canonical form of the body part, and thus can only be applied to
leaf body parts, and leaves headers unprotected? Or something different?

One version that would have a chance of "solving a different problem"
would be making the signature into a variant of the "packing list" scheme
found in some other mail systems, sort of like:

Content-type: application/grotty-signature-scheme

1 header 310874609872134
1.1 header a1349563876bc3f
1.1 body 7bit a38483413467
1.2 header 109875660924
1.2 body 8bit 1934710966

which would allow an MUA to say things like:

"The headers of the enclosed message (part 2) were damaged in transit.
The content of part 2 is FUBAR, probably because the idiot sender
sent it in 8bit and the brain-damaged firewall downgraded it even
though the RFCs say you can't".

Security-wise, it allows you something like "a little bit pregnant".....

                     Harald A

 

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Fri, 14 Aug 1998 14:06:13 -0700
To: Rick Troth <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

At 9:01 AM -0700 8/14/98, Rick Troth wrote:

>	The world changes,  and people try to get machines
>to do things that they couldn't do before.   I fully expect more
>use of character recognition,  so that documents will get scanned
>from paper.   In that scenario,  leading white space  *might*  survive,
>trailing white space will probably be lost,  and intermediate white
>space will be hard to quantify as anything more than  "just a blank".
>Even today,  this behavior is seen in cut-n-paste operations.

The draft makes allowances for loss of trailing white space; the text
simply becomes format=fixed, and we are no worse off than we would be
without format=flowed.  Leading and intermediate white space is
irrelevant to the draft.

Date: Fri, 14 Aug 1998 14:10:15 -0700
To: Ian Bell <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: draft-gellens-format-00
Sender: [email-masked]

At 7:32 AM -0700 8/14/98, Ian Bell wrote:

>However, I think the version as written up does not cope with "real"
>messages as well as my original suggestions did. In particular, the
>draft only allows the identification of two sorts of lines: lines that
>are terminated by "soft" line endings and those that aren't.
>
>There are actually two sorts of lines that are not terminated by "soft"
>line endings: those that form the last lines of paragraphs and those
>that are not intended to be wrapped at all. The distinction is vital but
>this draft seems to confuse the two.

This was done in the interest of simplicity.  It seems likely to work
well enough to be useful, and is very simple.

>Any short paragraph containing, say, 70 characters may be sent as a
>single line tagged with a "hard" line ending, but should be wrapped by
>receiving software as appropriate. On the other hand, other sorts of
>lines should not be wrapped by MUAs at all. These would include lines
>being quoted from standard text/plain messages, the standard signature
>separator line and lines forming parts of tables etc.

The problem of wrappable but short lines is an interesting one.  I'd be
interested in hearing what other people think.

>If there is no way to tag a line as "don't wrap this", replies to
>standard text/plain messages MUST NOT be promoted to format=flowed

Promotion to format=flowed should be done with care, and probably only
under user direction, as I see it.  It's the safest course.

>Comments were solicited as to the UseNet signature convention. Since I
>think that a considerable merit of the proposal is that it may be used
>in mixed MIME/non-MIME arenas (mailing lists, UseNet), I consider it
>_most_ important that the integrity of "-- " is preserved. In any case,
>the convention is also often used in email messages - this one for
>example!

Many people generate it, but does anyone care about it on reception?

>Both of [my] points would be addressed by using my original mark-up
>scheme: any line ending in zero or one trailing space SHOULD NOT be
>reformatted: two trailing spaces implies end of paragraph: three
>trailing spaces implies soft end of line.

I'm not sure the added complexity is worth it; I like the idea of
keeping things as simple as possible.  One concern I have is that if we
try and do too much, we end up not being able to do anything.  I've
seen that happen a lot in the IETF.  I'd rather see something super
simple that solves a basic problem than shoot for something more
complicated that ends up never getting support.  But I'd be interested
in what others have to say.

>If this draft is to proceed, it is also important that it should specify
>that sending agents SHOULD prepare messages with lines that are wrapped
>at no more than 72 characters. This will ensure that format=flowed
>messages conform to best-practice text/plain messages and that
>recipients will not be inconvenienced by over-long lines.

Good point.

>To cope with MTAs that strip trailing white space, it is important that
>zero trailing spaces means "don't wrap". On the other hand, I'm not so
>sure that it is worth the effort in coping with MTAs that add white
>space in the way that the current draft attempts to do.

The current draft does not propose any efforts to protect against this.
It does
mention a possible strategy, but says it does not appear to be worth
the added complexity, and solicits comments.

Date: Fri, 14 Aug 1998 11:01:04 -0500 (CDT)
From: Rick Troth <[email-masked]>
To: [email-masked]
Subject: Re: draft-gellens-format-00 
Sender: [email-masked]

		"We reject kings, presidents, and voting. 
		We believe in rough concensus and running code." 
			-- Dave Clark 1992 
 
	Ian was trying to ensure that certain essentials were kept 
in the proposal,  seeing that it has survived beyond a "kill it" 
concensus.   I haven't followed as closely as I should,  but think 
the idea of yet-more-dependence on white space is flawed. 
 
	Here's what I said ... 
 
---------- Forwarded message ----------
Date: Fri, 14 Aug 1998 10:03:47 -0500 (CDT)
From: Rick Troth <[email-masked]>
To: Ian Bell <[email-masked]>
Subject: Re: draft-gellens-format-00

	I've been trying for several years to stamp out 
dependence on certain characteristics of white space 
because they consistently break things. 
 
It has been said  (and this may be just industry legend) 
that when the original author of  'make'  had gone home 
and gotten a decent night's sleep,  he was aghast at the 
realization of what he had done.   But it was too late, 
make was  "out the door"  and everyone loved it so much 
that there was no changing it.   So  'make'  to this day 
has an annoying dependence on <TAB> -vs- <SPACE>. 
 
	I would argue that 
 
		+	any mixture of TABs and SPACEs 
			should be treated as a single instance 
			of white space 
 
		+	leading white space is significant 
			and should by all means be preserved 
 
		+	trailing white space is not significant 
			and should neither be required nor prohibitted 
			(that is, programs should not care 
			whether it's there or not) 
 
	This is NOT TO SAY that any program should make adjustments 
to a data stream it carries from source to target,  only that we 
should not build dependencies on trailing white space, the kind of 
characters (TAB or SPACE), or the number of characters in a single run. 
 
	The world changes,  and people try to get machines 
to do things that they couldn't do before.   I fully expect more 
use of character recognition,  so that documents will get scanned 
from paper.   In that scenario,  leading white space  *might*  survive, 
trailing white space will probably be lost,  and intermediate white 
space will be hard to quantify as anything more than  "just a blank". 
Even today,  this behavior is seen in cut-n-paste operations. 
 
	I hope both you and QualComm will reconsider. 
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Fri, 14 Aug 1998 15:32:06 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: draft-gellens-format-00
Sender: [email-masked]

                Comments on draft-gellens-format-00
                -----------------------------------

When I first proposed the use of trailing white-space as a solution to
the "text as paragraphs" problem, the consensus seemed to be that this
use of trailing white-space was a kludge and in any case wouldn't get
implemented by the abusers of text/plain.

Nevertheless, I still felt that even if it didn't get adopted by the
text/plain abusers, it was still an idea that would allow conformant
software to wrap text for the benefit of their own users without
affecting the users of other software in any way at all. Its potential
adoption by a major player, Eudora (the idea has been written up by
Qualcomm), gives that idea more credence.

However, I think the version as written up does not cope with "real"
messages as well as my original suggestions did. In particular, the
draft only allows the identification of two sorts of lines: lines that
are terminated by "soft" line endings and those that aren't.

There are actually two sorts of lines that are not terminated by "soft"
line endings: those that form the last lines of paragraphs and those
that are not intended to be wrapped at all. The distinction is vital but
this draft seems to confuse the two.

Any short paragraph containing, say, 70 characters may be sent as a
single line tagged with a "hard" line ending, but should be wrapped by
receiving software as appropriate. On the other hand, other sorts of
lines should not be wrapped by MUAs at all. These would include lines
being quoted from standard text/plain messages, the standard signature
separator line and lines forming parts of tables etc.

If there is no way to tag a line as "don't wrap this", replies to
standard text/plain messages MUST NOT be promoted to format=flowed as
the original message may use non-standard quoting methods. My great
concern with text/paragraph was that it is only possible to reformat
quoted material if the quote character is explicitly defined.

Since by far the most common text format will continue to be
format=fixed (as this includes all existing text/plain and all non-MIME
messages), this proposal will be of little use if replies cannot be
promoted to format=flowed.

Comments were solicited as to the UseNet signature convention. Since I
think that a considerable merit of the proposal is that it may be used
in mixed MIME/non-MIME arenas (mailing lists, UseNet), I consider it
_most_ important that the integrity of "-- " is preserved. In any case,
the convention is also often used in email messages - this one for
example!

Both of the above points would be addressed by using my original mark-up
scheme: any line ending in zero or one trailing space SHOULD NOT be
reformatted: two trailing spaces implies end of paragraph: three
trailing spaces implies soft end of line.

If this draft is to proceed, it is also important that it should specify
that sending agents SHOULD prepare messages with lines that are wrapped
at no more than 72 characters. This will ensure that format=flowed
messages conform to best-practice text/plain messages and that
recipients will not be inconvenienced by over-long lines.

To cope with MTAs that strip trailing white space, it is important that
zero trailing spaces means "don't wrap". On the other hand, I'm not so
sure that it is worth the effort in coping with MTAs that add white
space in the way that the current draft attempts to do.

To conclude, MUAs conforming to a format=flowed proposal would be able
to display all outgoing messages/articles neatly to their users with PS
fonts without recipients using non-conformant MUAs being aware of the
fact. Depending on whether major MUAs implement the proposal, the
display of incoming messages would similarly be enhanced.

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