ietf-822
[Top] [All Lists]

draft-gellens-format-00

1998-08-14 07:31:25

                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

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