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.
Right and I think we're facing the need for incompatible change with the
nowsp fix that's needed. I'm not opposed to that even though I'm supporting
a large DKIM installed base right now.
I wanted to say though that there are three levels of compatibility here:
(a) Compatibilty with the existing DKIM "infrastructure" - by this I mean
the thousands of deployed keys already compatible with DKIM today (most
coming over to us from DK)
(b) Compatibility of existing source-code libraries and tools for DK/DKIM
(c) Compatibility with existing, DKIM-enabled, and deployed real-world
products
Now, we pay programmers to deal with (b) with hopefully not too much whining
about it so I'm not overly concerned there. We are facing (c) anyway with
the nowsp fix but this becomes more and more painful as time wears on and
the deployed base grows. I view the possibility of having to deal with this
head-ache as part of the price of being an early adopter. In my own case, I
can deal with it. Item (a) is the most important aspect of compatibility.
Every effort must be made to maintain this level of compatibility. This is
because, unlike (b) and (c) which vendors and programmers can deal with and
are paid to deal with, (a) is at the end-user level. If we create
incompatibility here we lose a great deal of traction.
--
Arvel
_______________________________________________
ietf-dkim mailing list
http://dkim.org