ietf-822
[Top] [All Lists]

Re: Format=flowed delsp=Yes and quoted-printable

2003-08-18 11:21:33

A bunch of responses in one message:

On 8/15/03 at 1:49 PM -0400, Keith Moore wrote:

OK, then let's do a small thought experiment: Why would you need long lines in English (of course, that are not otherwise addressed by format=flowed)?

wide tables or "ASCII art", lots of columns of data, data files that are in character format but not really intended for human consumption.

And which of those would you ever send in a format=flowed message? (Remember, the original issue I was answering was why you should never send QP with Japanese in format=flowed.)

On 8/15/03 at 8:40 PM +0200, Marc Mutz wrote:

As I see it (and Pete has just reinforced my view on this by sharing it), format=flowed's main feature is to define paragraphs (in unquoted, but more importantly also in quoted text) and an algorithm for preserving that information on replies.

Not quite. The main features of format=flowed are:

1. To give *plain text* clients the ability to re-wrap paragraphs (especially in quoted text) for display. (Of course, this is most important for clients with smaller screens.)

2. To give clients the ability to reformat reply messages so that quoted sections (even if they are excerpted from the middle of a line) are reasonably wrapped and displayed upon receipt.

There are two important things to note about these features: They are about *display* and they are about *plain text*. Whatever gets to the other side has to be easily and reasonably displayed by any plain text reader. The least common denominator you are shooting for is that someone who ignores that "format=flowed" parameter will do OK. The best you want is that someone who honors the parameter will be able to do fancier things. Reliable semantic transmission is not the primary goal. If you really want to preserve the semantics of paragraph and quoting reliably, you should be using HTML or XML or some other markup.

However, that requires trailing whitespace to be preserved, since line-coupling to paragraphs is lost if TWS is. In my experience, "preserve TWS" evaluates to "apply QP". Now, that is not suggested (not to say forbidden) for readability reasons with legacy (non-QP-aware) MUAs.

If your primary purpose was to preserve semantics, preserving TWS would be required. Since that's not the primary purpose, it is not necessary, and more importantly not desirable.

IMO, priority should be on preserving the information for "modern" MUAs, not on enhancing readability for legacy MUAs[1].

That's why you have HTML.

On 8/16/03 at 4:45 PM -0400, Nathaniel Borenstein wrote:

On Friday, August 15, 2003, at 12:03  PM, Pete Resnick wrote:

When you put it back together, what you get is a single long line that (for example) should be displayed with a horizontal scrollbar. It is a representation of a single line, not a wrapped paragraph.

The latter sentence is true, but I have a quibble with your use of the word "should" in the previous sentence. The fact that the data object being displayed is properly understood as a single long line of text does not mandate the choice of one display mechanism over another. In this case, I would contend that inserting soft line breaks and avoiding a horizontal scrollbar is more often than not the more user-friendly thing to do.

If you had said "might" instead of "should" I would have kept my mouth shut. -- Nathaniel

On one hand, you're correct: The reality of the world is that clients do dumb things, including marking things as quoted-printable long lines even though they really don't intend to convey that this line really *should* be displayed as a single line with a horizontal scroll bar. On the other hand, a client with a 30 column display which chooses to display:

     Stupid              Smart
     Pete Resnick        Nathaniel =
     Borenstein

as:

     Stupid              Smart
     Pete Resnick
     Nathaniel Borenstein

instead of using a scrollbar and showing:

     Stupid              Smart
     Pete Resnick        Nathaniel Borenstein

is doing their user a disservice. If we are strictly talking about preserving semantics, you *should* use the horizontal scrollbar. If we are accounting for what sending clients incorrectly transmit in the semantics, you are of course correct that we might want to do something different.

pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102