AD> This is not an argument. Those users are using MUAs.
The authors
AD> of those MUAs can do the work, and add a checkbox that
the idiot users
AD> can use.
For the IETF, it is the _only_ argument. Folks forget that we exist
to produce specifications that get used. Not "implemented" but
actually used.
The IETF has been spectacularly unsucessful by this criteria. The
vast majority of the 'IETF' specifications predate the first meeting.
HTTP, SSL, LDAP were all successful before work started in the IETF.
Only in a very small number of cases has there been any success in
changing an already deployed protocol. This is not intrinsic to the
problem though, it is a fixable feature of the way the Internet is put
together.
Thinking about deployment is important, but there is not a single
specification that does not require some change somewhere - otherwise
there would be no need for the spec.
For an example of the "it got implemented" criterion that ignored the
"it gets used" criterion, please refer to the history of OSI.
The history of OSI shows less than many claim. OSI came into existence
because European computer makers and the US government feared that
IBM's SNA would become a defacto proprietary standard in the same way
that the IBM PC did.
OSI failed for one reason alone, it missed the window of opportunity by
a couple of years. The Web killed OSI, the Internet and the IETF had
nothing to do with it. Once the Internet became the 'anyone but IBM'
candidate the support of pretty much everyone apart from the US
civil service switched to it. And yes there are folk in the USG
still plotting the deployment of X.500
The Internet is under-engineered, OSI is over-engineered. Neither has
any real impact on the success of a computer protocol. The second,
third and even fourth rate succeed all the time. OSI is tame
compared to the protocols used in telephony.
That is my point. The nature and amount of incentive needed depends
on the cost and the benefit (along with a few other factors, of
course.) Any scheme that proposed massive change needs to pay quite a
bit of attention to the both of these. That requires detailed
thinking, not a simple handwave.
It is not the benefit that matters, it is the perceived benefit. The
potential benefit does not move the market unless people have a very strong
belief that it will succeed and that there is an advantage to being
an early adopter.
AD> And we already know that people who won't upgrade won't be doing
AD> anything to help solve the spam problem. We can ignore
any arguments
AD> about their needs, as they've already made their choice
to accept the
AD> current situation.
That line of thinking is quite popular in the technical community, and
often even in the management community. It accounts for a massive
number of companies' failures. As well as standards' failures.
The spam problem will not drive the deployment of any authentication
mechanism. That is not the problem they are designed to solve.
The problem they do solve is the 'get my email through' problem. This
is at least as large as the spam problem. I just got an email from someone
who owes me $1390 I did not know had not been paid. It had been marked
as spam.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg