On 5/18/22 19:53, Jim Fenton wrote:
Reading this long thread on the introduction problem and all sorts of other things reminds me that it isn’t productive to try to solve all of email’s problems with a single protocol. Email evolved as an easy way to contact basically anyone, and as a result got used for a lot of applications with different (and even conflicting) requirements. We should be working defining a number of protocols that handle some of the things that email is used for today, and that email doesn’t do well.
This doesn't sound right to me at all. Just because email is used for so many different things (some of which are a better "fit" than others) doesn't mean that people's burdens would be reduced by managing many more applications/services than they do now. And while we could find more efficient ways of delivering some of those kinds of traffic, doing so wouldn't reduce the burdens on end users, and could easily make their situations worse.
(If anything, email might be too efficient already... so efficient that email has become the last-resort way of delivering any kind of message whatsoever, even if (or especially if) it is of very low value to the recipient.)
The situation that exists today is arguably one of too many messaging services. It used to be the case that a well-connected individual might have multiple email accounts - UUCP, BITNET, CSnet, etc. so as to be maximally reachable by others. These days it's not unusual for a person to have multiple email accounts (in case email to one is blocked by a spam filter) AND also facebook, linkedin, twitter, etc. accounts. In the old days there was at least some interoperability between some different email systems; these days there is basically none.
And though there might be a few advantages of some of these alternative services, most of them are profoundly dysfunctional in most ways when compared to email.
Keith
