--On Sunday, 20 August, 2023 12:11 -0400 Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: > On Sat, Aug 19, 2023 at 11:11 PM John C Klensin > <john-ietf@xxxxxxx> wrote: > >> p.s. The other advantage of plain text over HTML mail is a >> security issue. The former is far less likely to provide a >> vehicle for privacy disclosures or actual security problems >> than the latter. To a certain extent that is a >> implementation issue, but I do not believe the IETF has >> issues a standard or BCP for that absolutely safe render of >> HTML email body parts. >> > > That is entirely the fault of the IETF. The IETF needs to own > it. > > If this organization wants to be relevant, it has to respond > to what the users want. And those users have made clear that > they want *bold font* and *italics* in email. They also want > proportional fonts with section headings. > > So either the IETF should have written a safe subset of HTML > for use in email or it should have asked W3C to do the work. Now that particular argument is interesting, of only historically. The one piece of the puzzle the IETF mostly did invent was something called "Rich Text". IIR (it has been years since I looked at the spec and don't have time today) it would have given you bold and italics and, if wanted, section headings. I don't remember what it would have done about proportional fonts, but the want/need for that is probably more controversial than your statement above indicates. Nor do I know whether what Microsoft and others call Rich Text today is the same thing or compatible. What happened to it? Well, it is still supported in a few MUAs today but basically it got swept away in the "HTML over everything and is everything" wave (what you describe as hijacking below included). I doubt that there is any way to go back, but the idea of requiring either plain text or Rich Text in mail to IETF lists has at least a bit of amusement value. > HTML was hijacked by Netscape which dumped in a large number > of extensions that were in most cases poorly thought out and > badly executed. The first iteration of Javascript was coded in > two weeks and boy did that show. It took five years to make it > stable and it was over a decade before AJAX became a popular > tool as a result. > > We don't need or want a vast amount of formatting in email > messages That statement is identical to one were made during the RichText effort. > and we certainly don't want javascript. We want > images but those need to be sent in a fashion that doesn't > compromise privacy. Links to external resources are > problematic because SMTP is problematic, it lacks originator > authentication and no DKIM is not that, it is only > authenticating the sending service. > In 2023, I should be able to send an invoice in email as a > message, not an attachment. Another historical factoid: The MIME design and vocabulary basically eliminated "attachment" as a term in email so, for the case of IETF specifications, I don't know what an "attachment" even is. best, john
