RFE: use patchwork to submit a patch

[Mark Brown]

On Mon, Nov 11, 2019 at 10:35:10AM +0100, Dmitry Vyukov wrote:
> On Sat, Nov 9, 2019 at 5:31 AM Theodore Y. Ts'o <tytso at mit.edu> wrote:

> > Essentially format=flowed is only supposed to be used when it's
> > considered OK for the receiver to reflow (or not) the lines any darned
> > way it wants.

> But for me the point re email still stands: why are we even spending
> time discussing this? Why are there such extensions with MAY status?
> If one doesn't care if the received with recover the original message
> or not, why caring adding/specifying these "format=flowed;
> delsp=yes"?...

> Obviously somebody in the middle got confused about these flowed/delsp
> as well and either assumed that they are MUST or assumed that
> preserving precise text for emails is just never important...

Not sure if you're looking for a serious answer here or not and it's not
really your point but the use case for format=flowed is for plain text
mails.  The sending MUA should flow the mail into 80 columns so it will
render OK as text but if something wants to reflow (eg, to fit within a
window) like it would for a paragraph in HTML mail then it can.  It's
optional so that things where the formatting is important don't get
disrupted.

> Regarding another mail agent: again this only proves the point for me:
> this is what tool developers are forced to be spending their resources
> on, rather then working on adding more useful features...
> I don't even know where to start re switching mail transport; how much
> the switch will cost? what are other transport costs in the long term
> maintenance? what are their problems?

We're not going to get away from interoperability problems no matter
what we use, especially if we are mixing things intended for human and
machine consumption.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20191111/f14956b6/attachment.sig>