"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.
This can open up a political can of worms.
I agree that the can is open, and that we ought impose
some compatabililty requirement in the charter.
However, I'd quibble with the above (which is btw, *much* better
than the "minimal" phease), in that 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.
(Questions: Is parallel operation needed? If so, need that apply
to a single message?)
Concrete example: if the dkim wg decided to move the DKIM-signature
field as input to hashing from after the body to being the first
input (e.g. so we could perturb hashing with some of our own
randomness), then that'd be incompatible on-the-wire, but no
problem for migration.
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org