ietf-822
[Top] [All Lists]

Re: draft-gellens-format-03.txt

1999-03-10 16:43:28
At 1:59 PM +0000 3/5/99, Charles Lindsey wrote:

Although the usual way of quoting, when replying to news/email, is to stick
a single '>' on the front, there are other possibilities, one of which is
'> '. But the proposal as it stands will completely screw up on that. We
need to think about this, because the present text of the usenet-format
proposal actually recommends '> ' as an improvement over '>'. I daresay we
could be talked out of that, but a safer way might be to have specific
parameters which could be set in the Content-Type header to say what the
quote-character and/or the stuffing-character should be.

The original version of the draft permitted either ">" or "> "; a subsequent version used "> " only, and now we are at ">" only.

Since this is a new format, I think there are several advantages to picking one canonical quote indicate and sticking to it. Allowing options, or making the quote indicator an additional C-T parameter, adds complexity with very little benefit.

If we have one quote indicator, it makes the proposal a little easier to understand and implement, both in generation and reception.

If a receiving mailer understands Format=Flowed, it can display quoted text in any desirable way (current betas of Mac Eudora, for example, optionally display quoted flowed text using excerpt bars). If a receiving agent does not understand F=F, it appears as if the text was generating using the most popular quote indicator (">"). And I say this as someone who personally prefers "> ".

Indeed, this whole proposal looks a little on the slim side - it solves
one real problem, but only one. There is a scheme by Brad Templeton (which
I have not looked at yet) on
<http://www.templetons.com/tech/proletext.html> which you ought to look
at. I gather that, by using mixed tabs and spaces at the end of a line, it
can encode all sorts of behaviours (anything that can be expressed in
binary), and even more if used on an empty line. And, like your scheme, it
defaults to plain text if it breaks. It may indeed be more complex than is
justified, but I think you should at least have a look.

Yes, it is a slim proposal, that solves mainly one problem. That is the goal. I think it is very important to have something that is very simple and can be quickly implemented. Anything more complex will be harder to get consensus on, and take longer to get it right and then implemented and deployed. So, I take your comment as evidence that this is on the right track :-).

I did look at the proletext proposal, and it is interesting. If Format=Flowed is a success, I think it would be worthwhile to then consider advancing proletext or something like it, as an additional format type. But I think we should get F=F deployed first.



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