newest Draft Charter:
the DKIM working group will make every reasonable attempt to
keep changes compatible with what is deployed, making incompatible changes
only when they are necessary for the success of the specifications.
versus
Stephen:
I don't believe there is a
requirement for the dkim standard protocol to be backwards
compatible on-the-wire with what's deployed today, but rather
that the dkim standard be such that it's not a problem to migrate
from today's deployments or perhaps even to run them in parallel.
Folks have been expressing support for the new charter text. I'm
inclined not to perturb that, but have a continuing concern that forces
me to probe one issue: We should make sure that there is a reasonably
clear view of priorities for preservering installed base... or not.
Is it ok with folks to be required to replace essentially all of the
current software, administration and user deployment?
The new draft charter would seem to impose a very high barrier on
changes that render the new specifications incompatible with existing
implementations. It's language is similar to that of other IETF efforts
that seek to minimize incompatibilities.
However Stephen's comment creates a much, much lower barrier, and is
concerned only with stored data that are queried.
Both are views reasonable, depending upon community need. My guess is
that the IETF's version of DKIM will deploy in about a year, if we are
lucky. So that the migration disruption would occur around then, and go
for a year or two.
(For reference, the DKIM pre-IETF effort similarly debated this point
extensively, relative to DomainKeys compatibility. It's never an easy
choice.)
d/
_______________________________________________
ietf-dkim mailing list
http://dkim.org