On Thu, Jun 12, 2014 at 10:19 AM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
My point is that mail is an old protocol and people who expect that it
can be kept going unaltered in its original form serving all the
purposes that it was never designed for but have emerged over time are
going to be upset no matter what.
This is a variant of the usual refrain, over the last 20 years, about
dealing with some limitation or other to email. It goes along the lines
of "We need to throw out SMTP and start over."
No, not quite. Think of it as we have a dying patient on the operating
table and we are going to amputate parts to keep them alive, replacing them
with prosthetics as we go.
Eventually the prosthetics will take over and we can replace the head. But
thats not where we are starting.
To this and the above I have my own usual refrain:
There will come a point at which SMTP (or IMAP, or the email object
or...) do need to be replaced. An appropriate procedure for deciding
when that point has been reached needs to be:
1. Get community (rough) consensus about the non-technical
characteristics for the functional change; that is, agreement about what
the community wants to do with/for email that it cannot currently do.
2. The email technical community has been successfully making
enhancements to the same continuously running end-to-end service for
30-40 years (depending upon how one counts); so give it a chance to find
a way to incrementally improve the existing service to support whatever
is needed.
3. When the technical community fails, it will be time to develop
the relevant protocol/format/whatever.
On the average, those calling for replacing SMTP (or whatever) have been
stopped at the first step.
Someday, they won't be.
But until then, meta-declarations about needing to replace Internet Mail
(or any other existing Internet service) don't have much practical purpose.
In the AI community they like to talk about problems being AI-complete,
that is if you can solve that problem you can solve all AI problems.
Pointing out that an approach is less likely to succeed than replacing some
of the email infrastructure seems a useful approach to me.
We do in fact have emergent quasi-mail systems including Dropbox like
things and blogs with subscriptions to comments that don't really fit well
in the email infrastructure either. My proposal was not to replace the
email core, it was to design a purpose built protocol for things email has
always done rather badly.