[ietf-dkim] DKIM BOF -- draft charter and agenda
arvel at altn.com
Thu Oct 13 23:29:11 PDT 2005
> 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
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.
More information about the ietf-dkim