On 6/2/2010 12:58 PM, MH Michael Hammer (5304) wrote: >> Since we've been seeing reports of breakage due to using ADSP records for >> domains that are not under sufficient control, it is clear that some >> fraction of the ADSP-using world does not understand what it is for, or at >> least what its limitations are. > > If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just > have to power down the whole internet. The best that we can do is come up > with something that makes a modicum of sense, fix things we didn't anticipate > or understand because we needed operational experience and move on. > > There will always be some fraction of the user/implementer base that won't > understand protocols, standards or RFCs. It kind of goes with the territory.
Mike, this is the sort of discussion disconnect that prevents making progress. I'm copying the list because it's a broad-based problem we are all having in trying to discuss issues. First, a question was put forward and I offered an answer. It is simply not fair to then respond in a manner that dismisses that answer (or at least dismisses it in this way.) Second, the usual way that services get successful is to look for problems in their use and look for ways to correct them. Simply saying that there are always some problems is not helpful. Third, we do not have massive amounts of ADSP success which permits marginalizing a tiny amount of problems. We have tiny use, with notable breakage. Fourth, it has become increasingly clear to me, at least, that there is broad-based misunderstanding of what can reasonably be accomplished with DKIM and what can reasonably be accomplished with ADSP, versus what cannot. Failure to gain broad-based agreement about both capabilities and limits ensures an on-going mismatch in expectations. If proponents want simply to keep automatically saying that things are great and keep automatically rejecting any counter-points, then I'm not clear what the purpose of these discussions is. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
