On 4/9/23 17:58, Phillip Hallam-Baker wrote:
I'm less interested in pointing fingers, than I am in bringing email into the 21st century. For what it's worth, my recollection is that MIME was a huge leap for Internet email. But MIME by itself pretty much only added attachments and multiple character encoding schemes to text-based email. In particular, it didn't explain how to use these facilities effectively for collaboration, and the data structures that native MIME represents don't translate in a simple and obvious way to data structures that (for example) allow effective annotations (over and over, by different people) to subject messages in replies.I agree with the sentiments but not the conclusions here.
Yes, HTML in email is a dog's breakfast. And whose fault is that? Who is responsible for email messaging standards? Well SMTP is IETF and HTML is W3C and HTML for email was allowed to fall through the cracks.
After MIME got out the door, it took a long time for the user
agents to catch up with even the modest increase in capabilities,
and even longer to start thinking about how MIME (along with HTML
which followed fairly quickly) affected how people would use
email.
(MIME had richtext, but I don't think it was obviously better for email than HTML of that time was. And some web browsers had email user agents built in, and those browsers already had HTML support, so HTML "won".)
I don't think even HTML/2.0 was a good fit. But the problems are a lot bigger than 2.0 vs 3.0 or later.The structural problem here is that the HTML that is appropriate for email is HTML/2.0 which is structured markup. HTML ceased being that when HTML/3.0 landed and it lacks the features required for email messaging which include the ability to mark sections of text as quoted. The handling of fonts etc. is idiosyncratic at best. But whose responsibility is that?
Yes, Github does have some features that can be used to support collaboration. But it is a collaboration flow engine wrapped around a source code management system and it is really not built for what we need for our work. So while it has some advantages, you have to be using Github *in a collaborative setting* pretty much every day to remember how it all works. The notion of forking a repository so I can submit a pull request in order to comment on something is obscurantism at best.
Agree. Really it's more of a coincidence that github can be made to work at all for collaboration on IETF documents, and it only works because lots of IETFers already know git and/or github, and IETF uses XML for its editable document format. But from a different point of view, both of those choices (git and XML) make it more difficult for people to participate effectively in IETF. And I still think that early in a document's life cycle, generating pull requests is a really poor way to collaborate, and not only because of the baroque user interface. PRs only work for collaborating on a technical specification when the document is already relatively mature and most of the changes needed are fairly localized.
Keith
