On Jan 7, 2011, at 3:48 PM, Rolf E. Sonneveld wrote:
• it has taken some four years to make DKIM what it is now. And with
that, I don't mean the protocol specification itself, but I mean adoption,
deployment, acceptance of DKIM, the level of knowledge about DKIM within
organizations, reputation of the spec. etc. Although the adoption rate may
seam slow, over time we see real progress in the percentage of DKIM signed
messages. Today someone forwarded me the following announcement of Google:
http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html
. My concern is that, after all these years, now redefining what DKIM is,
will certainly not help acceptance and deployment growth. It may work
counterproductive and it may make organizations afraid of investing in such a
changing technology, even if the changes are much smaller then they seem to
be. Technology is one thing, Public Relations is something completely
different.
• although I understand the reason why you would like to redefine DKIM
and make a distinction between the core elements (DOSETA) and the
mail-specific implementation of these elements (DKIM), in my view it's too
late to make this split. Splitting up these things will cause a lot of
confusion with the public (CEO's that need to decide whether to invest in
something like DKIM). Let us be realistic: today many people don't exactly
understand what DKIM does; the discussions about DKIM on this ietf-dkim list
illustrate this very well (see threads like 'What DKIM provides, again' and
'The usual misunderstanding about what DKIM promises' etc. etc.). Even on
this list there is no consensus about what DKIM really is. Splitting up DKIM
now will mean even less people understand what we're doing here and what DKIM
really is.
So to summarize: from a technology point of view it may be a good idea to
make this split, from a DKIM acceptance point of view this will turn into a
deception.
I absolutely understand where your concerns come from -- I've been working on
the political layer of DKIM for years too -- but I'm not sure I agree that this
split would cause us to return to the bad old days of companies refusing to
implement because it's "just a draft."
We'd still have DKIM, it'd still be called DKIM, and (I assume) it'd still be
in a document called DomainKeys Identified Mail (DKIM) Signatures. (Though I
wonder: would it remain RFC 4871 after the split?)
We'd also have a new thing, DOSETA, which we could (quite accurately) point to
as another example of the rightness of the original DKIM approach. And when
DOSETA is used to add an authentication layer to other technologies, the
proponents can approach the political layer by calling it "DKIM for foo,"
immediately gaining a positive comparison.
But the main reason I like the approach Barry and Dave have been describing is
that it gives us a way to take all this effort -- both technical and political
-- and apply it to other forms of messaging. Examples I've seen so far include
SIP calls, RSS articles, XMPP messages...and those are just the open, standard
protocols.
Even if there is some political risk -- and I admit there's some, though I
believe it'll be minor -- I'd say the potential benefits outweigh the risk.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html