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.