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