Dave Crocker wrote:
The POP->IMAP example is excellent, since it really
demonstrates my point. IMAP is rather popular in some local
area network environments. However it's long history has
failed utterly to seriously displace POP on a global scale.
Could that be because from the end user perspective IMAP doesn't provide
any clear value over POP? Isn't IMAP all about shifting control of the
mail store from the end user into the hands of the mail administrator? I
would claim this lack of clear value to the end user is not a valid
basis for arguing that people won't move, but it is one for arguing that
people need to know what they are getting in return for the effort.
EAH> Large-scale mail carriers would probably switch quickly if the
EAH> accountability feature proved useful,
and now we are back to hypothesizing about the behaviors of
mega-corporations with massive installed bases and a rather
poor history of adopting changes from the IETF community.
Seriously folks, if discussion about changes is going to be
productive, it needs to pay much more realistic attention to
history and pragmatics of ISP operations and average-user preferences.
We agree, the IETF has a very poor history of doing this. As much as
people hate requirements documents, their purpose is to get the
engineering team all focused on solving the same problem. Unfortunately
the few times there are requirements docs the IETF has a history of
discounting the needs of the end user or network operator, while it
places a premium on minimizing developer effort. In general the end user
doesn't care how elegant a protocol is (they never even know it exists),
they just care that the app works as advertised and accomplishes the
task they need done. When elegance reduces cost, they will gravitate
that way, but when it increases cost they will avoid it. Network
operators care more about the labor involved (in engineering time to
keep up with scale, and operator understanding) as that usually
dominates their costs. Elegant protocols mean nothing unless they lead
to improved service, reduced labor, or preferably both.
The IETF is in a difficult spot, because the customer of the IETF is the
vendor developer (in the generic sense of vendor as producer of things
used by someone else). Yet it is the customer of those vendors that
ultimately decide the value of the work and its deployability. If the
vendors do a good job of translating the protocol work into products
that meed a need, and market them well, the result will be deployed.
When not, we get cases like IMAP where there may be value, but the end
user doesn't know what it is.
In any case, the end user would know the value in a different mail tool
that made it possible to recover the cost of their time in dealing with
spam. By Joe-sixpack math, at 10 spam items per day and $100 potential
compensation, even after taxes that is $1/4M per year (tell me the
masses wouldn't switch with that kind of motivation). The lame spammer
that only gets out 10k messages per day would be facing $1M /day in
judgments. Politicians will sit up and take notice when cumulative
judgments across borders quickly reach the $1B range. We don't need
complex micro-payments to provide financial feedback. What we need is a
way for existing legal mechanisms to clearly nail down the originator.
Personally I think we could help law enforcement by providing the
lat/long of the source server on something like a 6.4m resolution, but I
am slightly biased about that approach.
Tony