ietf-822
[Top] [All Lists]

Re: text/paragraph or wrap=yes/no

1998-03-16 00:52:49
} Right now, the MIME documents make no claim about what the number of
} columns that you are required to keep your short lines too; the only thing
} it says is that you're supposed to send them short enough such that "It
} should not be necessary to add any line breaks to display "text/plain"
} correctly" (2046). My claim all along (with Laurence, Steve, and others I
} believe) is that this turns out to be an impossible requirement to meet
} because senders can't tell how short to make the lines from this dictum.

What that rule should be getting across (and apparently isn't) is that
a line break should -mean- the same thing to both the sender and the
recipient of any bodypart that is labeled text/plain.

Quite correct, and your point about people not picking up on this is well
taken. If there's something that needs to change in MIME it is this. However,
I've tried numerous times in this discussion to get this point across with
no success whatsoever. I hope your restatement here helps clarify matters.

What it means for recipient UA text/plain handling is:

* Don't add more line breaks unless there's no other way to show all
  the text (or unless asked to add them by some configuration option).
  Especially never display one line break as two; that is, a line break
  does NOT mean a paragraph break.

* Don't remove any line breaks.

(A corollary is that a sender who deliberately uses long lines, e.g. for
a table, can assume that recipients won't break up his long lines unless
they have no other choice.  A secondary problem with sending paragraph
text labeled text/plain is that recipient UAs get modified to compensate
by doing word-break folding on long lines, which then destroys display of
text that was intended to have lines left unfolded.)

The only requirement that senders have to meet is that, if they use the
label text/plain for a bodypart, then the recipient's UA can produce a
minimally sensible display of that part by following those two rules.

Note that this means that a sender -cannot- assume that a recipient will
fold long lines at word breaks.  In fact, given that (2046):

    Plain text may allow the stacking of several characters in the
    same position in the text.  Plain text in scripts like Arabic
    and Hebrew may also include facilities that allow the arbitrary
    mixing of text segments with opposite writing directions.

A sender can't even assume that a recipient knows what a word break -is-.

How much folding a UA that allows user input in paragraph format needs
to add in order to use the text/plain label, is a judgement call.  BCP
indicates folding somewhere between 70 and 80 columns, but that's only a
guideline.  The one thing that should be clear is that -not- folding at
all means that -no- recipient UA can display that text sensibly by using
only those two line-break rules.

And perhaps more to the point, the solution to this problem is _not_ to declare
that text/plain with lines longer than 80 characters is broken. This is
perfectly valid usage that we cannot break. 

The idea is to minimize the number of extra line breaks that recipients
may be forced to insert for display; the impossible task is to eliminate
them entirely, but that's not what senders are being asked to do.

Nicely put.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>