On 19 Oct 2012, at 17:45, Randall Gellens
<randy(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:
At 11:42 AM +0100 10/19/12, Sabahattin Gucukoglu wrote:
Warning: this message was generated by Apple Mail.
But not using Format=Flowed.
Precisely.
On 16 Oct 2012, at 03:46, Randall Gellens
<randy(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:
At 9:12 AM -0400 9/5/12, Michael Richardson {quigon} wrote:
Maybe I'm also concerned because many in the former "elite" have moved to
Apple Mail, and it seems that it is bug
compatible with Outlook in it's assumption that format=flowed is the
default, an act which destroys email quoting, and therefore discussion.
I just noticed this assertion, which is quite false. Format=flowed
protects and preserved quoting. It's the only way to avoid ludicrous and
impossible to read quoting (which happens after quoted passages get
line-wrapped at odd points). Also, as far as I know, Exchange does not
support format=flowed at all. My understanding is that it insists on HTML
quoting, which is entirely different.
You're right that this is the virtue of F/F, but that's not what Michael
said. Perhaps it was the context of the quoting, but the discussion refers
to the fact that both LookOut and Apple Mail have (as you can see, by
looking at this message) a nasty habit of *assuming* an F/F semantic by
default. In other words, they generate hugely long long long long long long
long long long lines that only another equally broken client can interpret
correctly, but dynamically reflowing those lines, by applying consistent
quoting indicators to the lines of such reflowed lines, and so forth. That,
I believe, is a legitimate complaint, because it e
This reflects a misunderstanding of Format=Flowed. Properly generated F=F
has lines of no more than 78 characters. One of the primary goals of F=F is
good interoperability between clients that support F=F and those that support
traditional pure plain text email. What you're describing is a symptom of
HTML quoting (or a surprisingly poor F=F implementation):
Yes, absolutely. We do not disagree.
Let's clear up the confusion. I made two mistakes, firstly by calling this
"F/F semantics" when what I mean is some sort of long-line-aware reflowing and
quoting. We'll have to find a name for it. The other mistake was to call
plain text plain text of any description, irrespective of the definition of
text/plain.
So we are talking about three formats:
* text/plain, 78 characters wide
* format=flowed, text/plain with soft breaks signalled by trailing whitespace,
78 characters
* text/paragraphs (or whatever), a completely different identity that violates
the length limits
Apple Mail and Microsoft use this text/paragraphs. It's not interoperable with
text/plain (because it *isn't* text/plain, as you very correctly note) and
therefore it gives everyone a really hard time. Unless you've not dealt with
plain text files from Windows or OS X, you may be sure that "Plain text" most
certainly doesn't conform to RFC 822, either.
We should now all be on the same page, I think. :-)
When generating Format=Flowed text, lines SHOULD be 78 characters or
shorter, including any trailing white space and also including any
space added as part of stuffing (see Section 4.4). As suggested
values, any paragraph longer than 78 characters in total length could
be wrapped using lines of 72 or fewer characters. While the specific
line length used is a matter of aesthetics and preference, longer
lines are more likely to require rewrapping and to encounter
difficulties with older mailers. (It has been suggested that 66
character lines are the most readable.)
The restriction to 78 or fewer characters between CRLFs on the wire
is to conform to [MSG-FMT].
At least Apple has the decency to use quoted-printable encoding to protect
the actual transmitted lines,
Again, this shows a fundamental misunderstanding of F=F. Properly generated
F=F does not use quoted-printable unless otherwise needed:
Yes. Apple Mail doesn't do this--it uses QP to keep the line lengths valid in
transmission only. Some mailers, or gateways, wouldn't do that, but would
instead spew out long lines that compliant SMTP servers would helpfully
corrupt, tail-drop, chop into pieces, etc (for lack of robustness or to protect
themselves).
but it means nothing if competent MIME readers reconstitute the corruption
at the other end, by reassembling long lines, and then failing to reflow
them. And it's worse yet if a news reader without MIME tries to quote the
lines, complete with Q-P line terminators. Or if a reply comes from
somebody whose editor wraps the lines, but using soft line breaks which are
never generated externally, resulting in whole paragraphs being quoted using
a single quoting indicator. And so on, and so on, and so on Š
All of these are part of the problem set that F=F was created to fix. Proper
F=F plays nice with pure plain text.
My first exposure to large numbers of affected people was on Usenet, when I
sent mail from Apple Mail through a gateway. Apparently, newsreaders fall into
the categories of having no MIME at all, or having MIME but not reflowing text.
In any case, they were unhappy. :-(
I filed bug 7989556 (Mail uses quoted-printable indiscriminately) with Apple
on 16 May 2010. It was marked as duplicate of 7547565 on 25 May 2010. The
system is closed; you can only see your own bug reports. I therefore have
no idea what's going on with that. Meantime, I apologise for the
inconvenience. No, really. :-(
I haven't looked into Apple's mail's generation of either F=F or plain text
or HTML. If it generates F=F with long lines and/or indiscriminate q-p, then
those would in my view be bugs that should be fixed. But I don't know if the
symptoms described occur with Apple Mail's F=F or some other format. To me,
they sound like lack of F=F.
At one point--in Leopard (10.5), I think--they were using F=F. It almost looks
like the current behaviour is what's left of the F=F implementation, in that it
renders and sends emails that can be flowed, though using text/paragraphs
rather than F=F.
Cheers,
Sabahattin