> 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 like it.
> * 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.
I think too much focus on forgery invites comparison with signature services
(which do a much better job, at least in theory, of dealing with forgery). I'd
have to see the actual text to be sure, but there's definitely a slippery slope
nearby.
> 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...
My suggestion would be to specify the milestones relative to the point where
the group is successfully chartered.
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org