ietf-822
[Top] [All Lists]

Re: draft-gellens-format-03.txt

1999-03-12 13:28:03
At 11:00 AM +0000 3/11/99, Charles Lindsey wrote:

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

Actually, you could allow either by letting the dequote/destuff cycle
iterate until exhaustion.

I'd rather keep things as two separate steps: first dequote, then unstuff. Otherwise you can't use space-stuffing to send a line with ">" as the first character, which is kind of the point. It also keeps things simpler.


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.
Indeed. The first quote character is under the control of the person who
generates the flowed format, so you _could_ insist on ">" as the only
supported possibility. However, the real problem is texts that come with a
variety of quoting standards, having lines beginning with ">|:" for 3
depths of quotation. Trouble is that many mailers allow you to choose your
quote character, and some people cannot resist the tmeptation to take full
advantage of all bells and whistles provided :-( . OTOH, I see no obvious
solution to that problem.

Previously-quoted text is either flowed or fixed. If it is flowed, we have no problem. If it is fixed, the safest action is to keep it fixed. If a mailer wants to convert from fixed to flowed, it will need to guess at quote characters and other aspects, probably with user input or direction. Either way, we are OK. If the text is kept as fixed, we are not using flowed, and so are no worse off then we are today. If the text is converted to flowed, it will obey the flowed notation.


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 :-).

No, I still think it is too slim. Consider the range of possibilities that
might be provided:

[snip]

I still think the proposal is best kept as is, at least for the initial version. I really don't want to add any more complexity. We already have enough (maybe too much).



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