--On Saturday, August 26, 2023 21:56 -0400 Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > On 8/26/23 21:33, Theodore Ts'o wrote: > >> On Sat, Aug 26, 2023 at 01:09:03AM -0400, Keith Moore wrote: >>>> For a good time, take a look at schema.org which has a >>>> whole bunch of sets of tagged HTML elements you can embed >>>> in messages and that a lot of large mail systems will >>>> interpret as things ranging from drug formulas to concert >>>> tickets. The SML WG is looking at standardizing it. >>> So what? We don't have to change the meaning of HTML that >>> people are already using in email, in order to define a >>> subset/profile of email for use in technical discussions (or >>> however else we want to scope it) >> The challenge is how do you *enforce* that e-mails conform to >> this subset/profile of HTML? > If, say, a list, or a recipient, wants to enforce a subset or > profile, it can do so by implementing a filter that removes > elements that don't conform to the profile. Of course. But removing elements risks changing the meaning of the message or at least of making it hard to understand. Of course, it would also invalidate any sort of message integrity checks (signatures or otherwise) on the original message, something we might or might not care about. > A list can, if it wishes, also bounce email that doesn't > conform to the profile, or that egregiously fails to conform > to the profile. Sure. But if the IETF were to adopt a specific profile and enforce it that way, I can see a few possible consequences: (1) If users compose mail in an MUA that provides good HTML support, accidental mistakes that would cause mail to be bounced or blocked would probably be inevitable. Independent of what that would do to the email traffic and delays in getting messages through, it would seem to me to be a good way to discourage participation in the IETF by all but the most dedicated. (2) If we set the precedent of a special profile for messages sent to our lists and enforcement of that profile as above, others might decide we were setting a good example. Some of them would then either adopt and enforce our profile or, more likely in many cases, develop their own variants on it and adopt and enforce that. That would amount to expecting originating MUAs to help their users by adopting per-destination domain (or address) validators or assistive tools. The implications of patterns like that to global interoperability of email should probably be clear. (3) We could do the obvious, define our special profile with a new media type of text/ietf (or maybe text/html+ietf or text/html-email) and then accept or bounce traffic based on whether or not the receiving list saw that media type. Unless there are far more composing MUAs and submission servers (counted by either number of systems or number of users) out there that allow the originator to specify whatever media type they like than I think there are, this would likely lead to a combination of the consequences of (1) and (2): discouraging participation in the IETF _and_ leading to (or encouraging) general interoperability problems. Tentative conclusion #1: If one wants to restrict IETF mail traffic to a special format, pick one that is already supported by an existing media type, not claim something is, e.g., HTML but then tries to require and enforce a special profile of it. I believe that leaves either text/plain or text/richtext (see below about the latter). > If tools to do these things become widely available and become > widely used by mailing lists, there will be pressure on MUA > vendors/authors to implement that subset. Sure. Do you have a realistic plan about making that happen? Before you answer, consider the likelihood that the vast majority of Internet users don't use mailing lists for discussions at all any more -- if they want to have a discussion, they turn to social media and/or some flavor of real time chat. Organizations and businesses, even non-spammy ones, who use mailing lists to distribute advertising or notifications are probably not good candidates for advocating your format either. Consider one of the mail service providers with millions of users and their own MUA(s), possibly web-based ones. What percentage of their users (and/or paying customers) do you think would need to ask for such a change (or put pressure on them) to get them to implement the subset? The answer may be different --and even more difficult-- if they have already implemented the superset because the users would not then be asking for increased functionality but restrictions in their editing/composing functions. Of course, that would be different if the "subset" were handled as a new media type, but, per the above, that would almost guarantee non-interoperability by any originating or receiving system that did not support the new type (the rule that unknown text subtypes can be treated as generic might help, but I don't know how much). > It's also possible that some mailing lists will develop > reputations of enforcing that subset, and that MUAs will learn > which lists enforce that subset and avoid sending > noncomformant HTML to those lists. Possible, yes. It is also possible that the pony I've periodically expressed a wish for over the years will be delivered to my doorstep, together with a plan about how to take care of it, tomorrow morning. I just don't see a path to demand for such a thing at sufficient scale to motivate such an occurrence. >> But what you are proposing is not requiring plain text, but >> some artificial HTML subset/profile. > Well, sure. Every new protocol is "artificial" until the > details are settled on. > Also, this presumably isn't an arbitrary variant of HTML - > it's presumably a variant that can display and operate > correctly on existing web browsers and MUAs that implement > HTML. And presumably the set of elements disallowed won't > be arbitrary, but will be those that fail to meet some > agreed-on criteria that are found to be reasonable for email. Yes. But, again, unless that variant is identified in some special way (and, most likely, even if it is) its being useful will depend far more on scale than on technical merit. And the collection of IETF participants just isn't big enough. >> And that might actually be a lot >> harder compared with sending plain text --- which some people >> seem to claim is Impossible(tm). (Which is fine, just don't >> bother the Linux kernel which is doing it when you try to >> claim that it's Not Possible. :-) >> >> It's not that hard to force MUA's to send plain text. But >> forcing MUA's to send an IETF custom HTML subset may be quite >> a bit more difficult. > I certainly don't believe it's impossible to restrict list > traffic to plain text. If that's what IETF Consensus > wants, I'm okay with it. I think there are some potential > benefits to allowing some XML-like structure in list messages, > and I lean at least slightly toward that kind of solution. > But that's not the only way to address the problems IETF is > having with email, and I also recognize that there are > potential benefits to extreme simplicity. Ok. Small disclaimer: I compose email in plain text form, read it that way when possible, and, when I need to read HTML email, do so through a very restricted reader/interpreter that will not automatically follow any links or otherwise process anything external. Part of the reason for that is perhaps that I'm some flavor of old person who is still stuck in the 1970s (not even the 1990s). But more of it is a security issue: just as I will not open a web page for while I don't have a reasonable degree of knowledge of the party and associated authentication, I am reluctant to open an HMTL email message without at least the same degree of knowledge and certainty. Now, I know the two of you well enough that, if I received an HTML message from you whose content was signed with a signature I could verify (not just some assurance that mail from you might reasonably come from a particular domain), I would have no hesitation about opening it. But for an IETF participants I don't know nearly as well, or a message whose signature cannot be validated (possibly because some list expansion software altered it to eliminate undesirable HTML elements), I get really anxious about what such a message might carry or do to me. There is also a privacy issue. I'm on several distribution lists from whom I periodically get a "we've noticed you are not reading our mail, is there a problem?" message. I seem to have the odd idea that they have no right to know whether I have opened their messages and when. I have no idea whether any of the reasons the Linux community has stuck to plain text are related to those security issues, but I would not be surprised. I think the following are plausible, while inventing a (different) special dialect or profile of HTML, enforcing it, and expecting enough others to be on board to make it really practical is, for the reasons given, probably not: (i) Require text/plain (ii) Reexamine text/richtext or text/enriched, if necessary updating RFC 1896. Unlike a new profile or media type, one or both of these is quietly supported in many systems. It is probably more plausible to believe that the implementers of those systems would do a minor upgrade to keep a media type they already support aligned with an updated standard than to believe they would adopt a completely new format (or profile). Allow/ encourage it instead of or as an alternative to text/plain. (iii) Instead of fantasies about alternate formats (or profiles) and getting them widely supported, see if we can write down, and get agreement on, good practices for use of email on IETF lists. Such practices might even include something along the lines of "if you are going to use HTML email, you should confine yourself to the following subset". If agreement can be reached, assume IETF participants are adults who can and will behave responsibly with those who don't risking having their messages ignored by some of the community. best, john
