[ietf-dkim] DKIM BOF -- draft charter and agenda

[Arvel Hathcock]

> 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