Re: [PATCH 1/2] mailinfo: support rfc3676 (format=flowed) text/plain messages

["Jay Soffian" <jaysoffian@gmail.com>]

On Fri, Feb 15, 2008 at 12:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I really do not like this.

Ugh.

>  format=flowed instructs the receivers MUA that it is Ok to
>  reflow the text when the message is presented to the user.

No, it indicates that the MUA sender mangled the message, but did so in
a way that it can be unmanged* as long as the receiving MUA implements
RFC 3676.

* Trailing whitespace removed by the MUA before sending is the one
  exception that cannot be unmangled; I'll address this further below.

>  You review the patch, decide to apply or reject, and then
>  finally apply.  Unmangling of corrupt contents should be done
>  before you review, not before you apply.

As long as you're reviewing the patch in an MUA which implements RFC
3676, you'll be reviewing the unmangled patch. By your reasoning,
mailinfo shouldn't decode QP or BASE64 either. If you want to make 100%
sure you're reviewing *exactly* what you plan to apply, then you need to
run it through git-am first and then review it via git-diff, no?

If you're reviewing in your MUA, your MUA may already be taking care of
QP or BASE64 for you. If the MUA is RFC 3676 aware, it's un-flowing
format=flowed too. mailinfo should do the same.

>  format=flowed is completely opposite --- you are
>  giving your and recipients MUA freedom to reflow the text, but
>  there is no valid reason to allow that when sending patches.

Not all MUA's can be configured to disable format=flowed. Sure, it's
best if folks send 100% plain/text w/o any mangling, but their MUA may
already be doing B64 or QP out of their control.

>  We do not even encourage MIME attachments and ask senders to try
>  sending uncorrupt patch in-line, _even though_ MIME attachments
>  is a way to try harder not to corrupt the payload.  Why should
>  we encourage format=flowed

We're not trying to encourage it, just accommodate it where the sender
can't disable it.

>  The format is not meant for the exact transmission of text (like
>  "patch") but more for paragraphed prose that can be re-fit on
>  narrower display like phones.  Section 5. even goes to say
>  "Hand-aligned text, such as ASCII tables or art, source code,
>  etc., SHOULD be sent as fixed, not flowed lines."

Again, some MUA's aren't configurable. They apply format=flowed to any
text/plain message.

>  Side note.  I did not look at the patch very carefully, but can
>  you salvage a deleted text in the patch that removes a line that
>  consists of "- " (minus followed by a single space and then
>  end-of-line), or any deleted or added text that ends with a SP
>  without making them misinterpreted as "flowed" line for that
>  matter?
>
>  I even suspect that the sending MUA client may misbehave for
>  such a patch line.  In fact, doesn't section 4.2 say "a
>  generating agant should trim spaces before user-inserted hard
>  line breaks."?  It implies to me that you cannot have a fixed
>  line that ends with SP.

Yes, the sending MUA likely striped trailing whitespace and this cannot
be recovered. Let's look at this in practice to see where it can be a
problem.

Existing code generally shouldn't have trailing whitespace nor
whitespace only lines. However, let's say that it does and that the
patch refers to one of these lines (either as context or a subtraction).
In this case that hunk will fail to apply, unless we teach git-apply to
be lenient if the only difference between the line in the patch and the
existing code is trailing whitespace.

In the case of an addition, the patch *shouldn't* contain trailing
whitespace anyway. If it did, git-apply would in its default
configuration flag it as a whitespace error. So arguably, the MUA is
doing you a favor by stripping whitespace on such lines. :-)

>  So just reject the patch when somebody sends you format=flowed
>  and ask them to re-send without =flowed, and the world will be
>  a much better place.

I don't get it. Why not accommodate fascist RFC 3676 MUAs if we can for
the same reasons we accommodate QP, BASE64, and attachments instead of
inline? I guess I can only think of two reasons:

1) We need to accommodate QP, BASE64, etc since they may be due to the
   MTA. By contrast, format=flowed is always an MUA issue.

2) The other transformations are 100% safe in getting back exactly the
   patch the user intended. format=flowed isn't. But per above, I'm not
   sure the trailing-whitespace loss is a problem in practice.

j.