Re: "> > >" space removal removes too many spaces?

[Simon Josefsson <jas@extundo.com>]

Florian Weimer <fw@deneb.enyo.de> writes:

> Simon Josefsson <jas@extundo.com> writes:
> 
>>> '>' may appear at the beginning of a line accidently, and we certainly
>>> want to supply the space character in this case.
>> 
>> First, wouldn't it be very complicated to solve your case?
> 
> No, I don't think so.  I think it helps to consider a leading '>' to
> be a quote character only if the preceding line is empty (or consists
> entirely of whitespace), or if it starts in turn with a '>'.

Ah.  It's not a complete solution then, but probably covers enough
cases to be worth it.

> I've just implemented this logic (at least I think so).

Looks nice.

>> I don't see how you programatically can easily separate your case
>> from e.g.
>> 
>>> According to your analysis
>>>>42 is a nice number
>>> you indicate that 42 is a nice number.
>> 
>> but suggestions are welcome. :)
> 
> Not leaving blank lines before and after quotes is not my preferred
> style of writing messages. ;-)

Mine neither, but I see it from time to time.

>> Secondly, RFC 2646 compliant MUAs should never generate this case in
>> the first place.  Even if you don't generate RFC 2646 (Gnus doesn't)
>> you could QP encode the character to prevent the ambiguity.
> 
> Does RFC 2646 really try to solve the problem this way?  In this
> case, the RFC is horribly broken.  Attaching semantic to QP encoding
> vs. not-encoding is clearly an extremely bad idea, and it certainly
> contradicts the spirit of MIME.

No, I think that approach is suggested in a couple of places, RFC 2015
being the only one I can find now (they use it to protect "From").
RFC 2646 suggests an alternate approach, space-stuffing the lines.  It
might be cleaner, but it's (slightly) less visually pleasing to
non-RFC 2646 clients.  The idea above looks good on all clients that
support QP.

The semantic of QP encoding vs unencoded is only in the generating
client, the receiver doesn't care.