Folks,
That is, they should be able to take the new IETF DKIM
specifications, implement it, and be able to process original DKIM
signatures.
Wow, that would be wonderful too.
More than whether it is wonderful is whether we choose to make it an
explicit goal or even a requirement. The language of the new draft
charter does seem to lean in that direction, yet I think I have still
seen postings that suggest a continuing disparity of views.
Since the current specification has demonstrated that it can work, it is
clear that the IETF effort can choose to maintain any degree of
interoperability that it deems reasonable.
My purpose in starting this thread of discussion was/is the hope that we
can formulate group consensus about what amount and type of backward
compatibility is required and what amount and type is desired.
Just to beat this point into the ground: The IETF effort is actually
going to work on version THREE of this protocol! DomainKeys was the
first. Pre-IETF DKIM is the second. Both have had a meaningful number
of interoperable implementations, but not massive numbers of
installations. So the nearly two years of development and testing
effort leading up to the IETF work justifies treating the IETF work as
"tuning" rather than starting anew.
Most participants clearly agree with this view, but some appear not to.
Stephen's statement struck me as possibly permitting less compatibility
than my own reading of the new charter text, and I know that there are
some participants who also have less concern about compatibility. And
as I've said, the choice of how much to require is never easy.
So I decided to press for this discussion in the hope that we could
achieve a very clear group rough consensus on the choice(s).
d/
_______________________________________________
ietf-dkim mailing list
http://dkim.org