[ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

[Dave Crocker]

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/