Subject: Re: Last Call: The Text/Plain Format Parameter to Proposed Standard

From: [email-masked] (Claus André Färber)
Date: 01 Apr 1999 20:30:00 +0200

[draft-gellens-format-05]

I believe it is inappropriate to overload text/plain by introducing a  
new parameter. Instead, it might be better to introduce a new content  
type, such as text/flowed.

As MIME-compliant user agents are required to treat unknown text/*  
content types as text/plain (see RFC 2045 ff.), this has no  
disadvantages for older MUAs.

Claus

---

From: [email-masked] (Claus André Färber)
Date: 01 Apr 1999 20:30:00 +0200

Claus

---

From: Ned Freed <[email-masked]>
Date: Thu, 01 Apr 1999 14:27:34 -0800 (PST)

> disadvantages for older MUAs.

In a world of perfect or near-perfect compliance with standards, I'd agree with
you. However, we don't live in such a world. And the operational reality is
that other subtypes of text aren't handled the way the MIME specification says
they should be. This then means that operationally this proposal is a
nonstarter unless it is done as a parameter.

This point was debated at considerable length on the mailing list. Tests
were also done to assess how the various different approaches would fare.

In many senses this is our own fault, as we've allowed the registration of
things under text which aren't even vaguely comprehensible when displayed
directly.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 01 Apr 1999 14:27:34 -0800 (PST)

Ned

---

From: Robert Elz <[email-masked]>
Date: Fri, 02 Apr 1999 21:05:18 +1000

Date:        Thu, 01 Apr 1999 14:27:34 -0800 (PST)
    From:        Ned Freed <[email-masked]>
    Message-ID:  <[email-masked]>

  | In many senses this is our own fault, as we've allowed the registration of
  | things under text which aren't even vaguely comprehensible when displayed
  | directly.

I have left the above text in just to make a point, I'm not proposing
commenting on that, or on the choice of text/plain with a parameter.

What I found "interesting" about the draft was the notion that quoted
include text is done by starting lines with ">", which is fairly common
but by no means universal.   Eg: see above for two styles...

What exactly to do about that, and keep "flowed" text at all (a concept I
would not mind seeing eliminated from the universe, though I understand its
appeal, there is no need for anyone to reply and tell me why it exists)
for quotex text anyway, is not at all clear.

Perhaps a quoted section of text could be defined as being a paragraph where
each (flowed or fixed) line (in the input) begins with a common non
alpha-numeric character (which allows a leading space (or tab) - ie: simply
indented text, as for the quoted headers above, and in fact, the quoted text
as well, the '|' isn't really the beginning character, the space is).

	At first glance it would seem this would break an indented paragraph
	such as this one, but if you think it through, it really doesn't.
	Were this paragraph a "flowed" paragraph, it could be reformatted
	according to the flowing rules, and then restored with the leading
	tab, and whether the software thinks it is doing that to display a
	quoted paragraph, or just an indented one, doesn't really matter in
	the slightest.

Then there's the problem of what do to with the quote counting, as simply
counting ">" characters won't do.   If I included the text where Ned quoted
Claus' original text, it might look like ...

| > I believe it is inappropriate to overload text/plain by introducing a
| > new parameter. 

or it might look like ...

  | > As MIME-compliant user agents are required to treat unknown text/*
  | > content types as text/plain

depending upon exactly how I did it.   I doubt that we can construct a method
that will work reliably.   Then again, I also doubt that anyone cares.
The point of "quote counting" isn't to actually know (in the software)
how many levels of quoting there are, it is to avoid flowing different
quoted text together.   For that, all that is required is to be able to
distinguish one quote from an immediately following one.   For that, perhaps
simply taking the "quoting indicator" as the sequence of leading non
alpha-numeric characters on each line, and whenever two (input) lines have
different quoting indicators, they should be treated as being different
quotes (that is, not flowed together).

The remaining problem I see is how to handle those who perfer to quote
as ...

 Claus> As MIME-compliant user agents are required to treat unknown text/*
 Claus> content types as text/plain (see RFC 2045 ff.), this has no
 Claus> disadvantages for older MUAs.

 Ned> In a world of perfect or near-perfect compliance with standards, I'd
 Ned> agree with you. However, we don't live in such a world.

If the text is indented like that, then the "leading space as a quote 
indicator" rule helps, though if the quotes weren't separated by a blank
line, it wouldn't help avoid them being treated as one common quote.
I expect some kind of heuristic could be developed even there though.
Things get a bit harder where the names of the authors (designators might
be better) aren't indented at all.   That might be one where the right thing
might be to simply adviise that the use of such a form in flowed text can't
be handled.

In any case, attempting to legislate ">" as the one true way of quoting
included text, or even to only be able to handle that case cleanly, and hence
attempt to force everyone into use it, simply isn't going to work.  It is
too late already.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 02 Apr 1999 21:05:18 +1000

kre

---

From: Dave Crocker <[email-masked]>
Date: Fri, 02 Apr 1999 18:34:15 -0800

>or it might look like ...

This specification has undergone pretty massive debate.  I've no doubt 
there are many ways to approach and tackle the problem it is trying to 
solve.  The question is whether this specification "won't work" or whether 
one or another of us simply would prefer differences in detail or 
approach.  Methinks the comments, so far, are the latter, not the former.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 02 Apr 1999 18:34:15 -0800

d/

---

From: Pete Resnick <[email-masked]>
Date: Sat, 3 Apr 1999 21:03:53 -0600

On 4/2/99 at 9:05 PM +1000, Robert Elz wrote:

>but by no means universal.

True, but pretty much irrelavent. First of all, you *can't* unwrap 
text coming from a current client with their myriad of quoting 
methods. The spec is real clear that "text/plain" without a "format" 
parameter is "format=fixed". So what current clients send out is 
irrelavent to a format=flowed receiver.

But even so, a flowed receiver who gets a quoted line from a flowed 
sender, however we decide that quoting should look in for people who 
don't have a flowed client (">", "| ", etc.), is going to reflow 
(i.e., unwrap) all of the lines in the quote for display. At that 
point, the receiver is going to have to put some appropriate display 
marking for "this is a quoted section". I can tell you that on a 
PalmPilot mail application, the last thing I want at the beginning of 
every line is "Claus> Ned> " taking up 12 of my 40 characters; I'll 
put some sort of simpler marking (like some number of vertical black 
lines) denoting the quoting level. The point is that "format=flowed" 
simply used ">" as quoting markup because it will look good to folks 
who can't handle the new parameter. Everyone who supports the new 
format will unwrap the text and do something appropriate to display 
it.

>attempt to force everyone into use it, simply isn't going to work.  It is

I'm sorry, I must have missed something: Why is it too late? What 
mailers who are sending out "format=flowed" are using other than ">"?

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

---

From: Pete Resnick <[email-masked]>
Date: Sat, 3 Apr 1999 21:03:53 -0600

pr