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
