On Monday 24 April 2017 16:22:26 Jan Kundrát wrote: > I see some similarities between that and sending inline patches. There's > MIME with its Content-Disposition: inline, but nope, let's revert back to > something which does not even support Unicode properly, and call that a > preferred solution. Because GMail does that, or because > $my_version_of_a_tool cannot be bothered to use a MIME library to parse > mail...
I would response just to this part, as I'm one of those people who (still) prefer plain text. There is one big problem with MIME: rfc specifications are too and heavy complicated and hard to write *correct* MIME parser. Another problem is that there are too many broken programs which generate MIME emails. And now when some tool needs to deal with content of email it has two options: 1) Accept only plain text and basically everything is inlined in (one) body of message. This is easy to parse and fully compliant with email standards (lets say RFC 5322). 2) Implement correct MIME parsing according to specification plus implement all hooks for broken MIME clients and try to parse it in best way and handle all options which could happen. If correctly implemented this would be also compliant to email standards RFC 5322, RFC204x plus others. And personally, I must admit that option 2) is really hard and in some languages probably impossible to implement due to broken MIME or email libraries which are commonly used. E.g. Java or Perl are not suitable. Btw, I'm trying to fix Perl email modules (which are widely used) to start generating compliant MIME emails, so I hope one time problem with broken generators can be fixed. So for now option 1) is the best what can be done. It is easier as 2) in most cases text body can be immediately parsed by program (without need to apply any filter or conversion code; e.g. sending diffs) and should work better for more email clients, as email clients still have support for classic RFC 2822 emails (without MIME). And because MIME is not mandatory for emails, I do not see reason why to force people to use it in cases it is not needed. Due to 2) there are still lot of server applications which prefer plain text emails (or totally without MIME support). Also I think most famous version control system -- git -- is also working with plain text non-MIME emails. -- Pali Rohár pali.ro...@gmail.com
