On 19 Oct 2012, at 17:45, Randall Gellens <ra...@qti.qualcomm.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 <ra...@qti.qualcomm.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
