Re: Quilt vs gmail (Was: [PATCH 0/3] sched/swait: Convert to full exclusive mode)

[Jean Delvare <jdelvare@suse.de>]

Hi Peter, Linus, Andreas,

On Tue, 12 Jun 2018 19:14:20 +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 09:47:34AM -0700, Linus Torvalds wrote:
> 
> > I do note how quilt emails are really hard to read, because that:
> > 
> >     Content-Disposition: inline
> > 
> > makes gmail think it's flowed.
> > 
> > Which works horribly badly for patches, surprise surprise.
> > 
> > So I really wish quilt wouldn't do that. It does smell like a gmail
> > bug, but at the same time, why would you use "Content-Disposition:
> > inline" when you don't have an actual multi-part email? So I do blame
> > quilt too for sending nonsensical headers.
> > 
> > (Yes, yes, I see the "It is permissible to use Content-Disposition on
> > the main body" in the RFC. But the RFC also makes it clear that it
> > actually matters for how things are presented, so saying "ok, I'll do
> > flowed" seems equally insane and equally technically RFC-compliant)  
> 
> Quilt people, anything that can be done about that?

The purpose of the Content-Disposition header is to let quilt store the
original patch file name, so that the recipient can save the email as a
patch file having the exact same name as the sender was using, to make
communication between developers easier. This is the reason why the
header is being added despite the email not being multi-part. As Linus
found out already, RFC 2183 allows that. The RFC also explicitly allows
the use of a filename parameter for inline parts (see section 2.3.)

Using "attachment" instead of "inline" would presumably force the user
to save the patch to a file before being able to read it, or, at least,
to take additional actions in the MUA to convince it to display the
contents inline regardless of what the Content-Disposition header
says. This is clearly not desirable.

We could try specifying the filename directly, without the "inline"
keyword, however that would no longer comply with the RFC
("disposition-parm" is optional, but "disposition-type" is mandatory)
and I am afraid that some MUA implementations would either default to
disposition-type "attachment" in this case, or ignore the header
altogether.

I'm not sure I understand what "flowed" means in this context. If you
mean that gmail breaks the formatting of the patch, I would say that
gmail is infringing the RFC, which clearly stipulates at the beginning
that the Content-Disposition header field is only about telling the MUA
which parts should be displayed immediately and which parts should not,
and not about presentation issues.

Considering that "inline" is the default for a non-multi-part message,
any MUA which changes its behavior in the presence of
"Content-Disposition: inline" is bugged in my opinion.
-- 
Jean Delvare
SUSE L3 Support