The point is that there's a significant deployment of some of this already out there, and we'd like to maintain compatibilty with that installed base, to the extent that it's reasonable to do so.
Yes, please! LOL.
If an incompatible change is Really the Right Thing, we should do it. But let's be sure that it's Really the Right Thing.
Agreed. How about something along these lines instead: "The working group recognizes that a significant amount of infrastructure and deployed software already compatible with the input specifications currently exists. The working group will therefore make every reasonable effort to refrain from introducing incompatible change."
* I want to make it much clearer, right in the charter, that no one thinks this will "stop spam", and that that isn't the intent of the spec nor the goal of the Working Group.
Agreed!
We do mention forgery, but I don't think we point out clearly enough that it's the forgery that this is addressing, and not other aspects of spam fighting.
Right. Apparently there were some problems with the use of the word "forgery" the first time around too. Forgery may need to be defined in the charter so that everyone is clear on our use of the term. One definition of "forgery" that I think works in this context is "use of a domain name in an email identity header without the consent of the domain owner". When you do that, you are guilty of "forgery" in the sense the original charter language intended (I think). Anyway, I agree the focus should be more on the "forgery" detection aspects rather than spam fighting.
Also: I know the milestones are extremely aggressive, and that's intentional. Those of us who've worked on getting this far want to move this work along *quickly*, because we believe that it's a critical component of the anti-spam/anti-phishing toolbox, and that we need it *now*. That said, let's look at those dates and accept "aggressive", but make sure they're feasible.
I think the dates in the original charter assumed we'd be further into the IETF process by now than has turned out to be the case for various reasons. In particular I think we should (at a mimimum) unshackle ourselves from the requirement to produce both the signing/verifying spec AND the RR spec by February. Work on RR hasn't even begun - there isn't even a draft of a draft or a draft yet. he he...
-- Arvel _______________________________________________ ietf-dkim mailing list http://dkim.org
