From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Apr 09 2002 - 06:10:54 CDT
In <XQFESoBzRbs8IATp@pillar.turnpike.com> Ian Bell <ianbell@turnpike.com> writes:
>On Thu, 4 Apr 2002, Charles Lindsey <chl@clw.cs.man.ac.uk> wrote:
>>If the non-RFC2646 client just happens to retain the
>>trailing spaces from the things already quoted in its precursor, then you
>>may still be able to reflow those lines in the manner I suggested.
>No, because the non-RFC2646 client will have downgraded the entire MIME
>part to text/plain, which by default means text/plain;format=fixed. In
>that case, trailing spaces do not signify soft eols and so can't be
>reflowed.
No, I don't follow you.
{Suppose the original RFC2646 client produces (using underscores to denote
trailing WSP):}
Content-Type: text/plain; format=flowed
This is a flowed message which clients with narrow windows_
may split at more places than is done here.
{So a conforming client might display it as
This is a flowed message which
clients with narrow windows may
split at more places than is
done here.
}
{Now it is received by a non-RFC2646 client which displays it as it was
sent, and creates a followup. Because it doesn't know any better, it
leaves the trailing space in place.}
Content-Type: text/plain
On 9th April "flowed client" wrote:
>This is a flowed message which clients with narrow windows_
>may split at more places than is done here.
to which we reply "what is this flowing nonsense"?
{This is received by some RFC2646 client which displays it as shown,
because it is not flowed. But that client then creates a flowed followup.
At this point, it finds itself in an awkward position. It is being asked
to quote and transmit a line with a trailing SP. It has been told that
this is a fixed line (because the incoming text did not claim to be
flowed). So it might decide to eliminate that trailing SP. But if it did
that, then it could be accused of munging the text it was quoting.
Alternatively, it might notice that the line it was being asked to quote
was already quoted, and so it might think to itself "perhaps the
original version of that line was flowed, in which case perhaps I should
leave the trailing SP anyway". Note that RFC2646 is entirely silent on
this matter. But if it DOES decide to leave that trailin SP alone, then
it will produce}
Content-Type: text/plain; format=flowed
On 10th APril "non-flowed client" wrote:
>On 9th April "flowed client" wrote:
>>This is a flowed message which clients with narrow windows_
>>may split at more places than is done here.
>to which we reply "what is this flowing nonsense"?
And to that we reply with a long explanation of what RFC2646_
is all about.
{And when that arrives at an RFC2646 client, it will be displayed as
On 10th APril "non-flowed client" wrote:
>On 9th April "flowed client" wrote:
>>This is a flowed message which
>>clients with narrow windows may
>>split at more places than is
>>done here
>to which we reply "what is this flowing nonsense"?
And to that we reply with a long
explanation of what RFC2646 is all
about.
}
Which is actually the "right thing".
So the question is whether the RFC2646 client was justified in leaving
that trailing SP in position, or not.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5