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