[ietf-dkim] DKIM tithing
dhc at dcrocker.net
Thu Jan 29 07:31:25 PST 2009
Steve Atkins wrote:
> On Jan 28, 2009, at 8:49 PM, Dave CROCKER wrote:
>> So I'd be interested in seeing your basis for believing that it is
>> an order of magnitude more complex that it needs to be...
> Look at the current thread. Removing just i= and it's friends would
> reduce the confusion *of people who are deeply involved in the spec*
> by a large factor.
As a measure of energy, that makes sense. I was thinking you meant technical
details; by that measure, i= doesn't take much. On the other hand, I suspect
that the amount of code affected by the d=/i= confusion probably is
> Going through the spec point by point, and painting big red circles
> around each element that adds more complexity than value isn't really
> the point, but look and see that many of the fields are OPTIONAL or
> RECOMMENDED and have reasonable defaults. What would the spec look
> like if they all went away and were replaced by the defaults? For the
> signer it would look much the same, as they can ignore all those
> fields anyway. For the verifier it would be much, much less complex.
So it turns out that an exercise like this is often part of the work done in
moving an IETF specification from Proposed Standard to Draft Standard: Look for
the features that have not gained traction and remove them from the spec.
I don't know whether DKIM is too young for such an exercise, but it might be
> There's also ill-defined implementation/semantics of multiple
> signatures, though I suspect local policy will likely make the
> vagueness in spec less of an issue, and it'll probably be cleaned up
> by a best practices document eventually (if it hasn't already).
In effect, that's an additional specification. That is, the base spec says how
to create and process one signature. That's the core capability. One can treat
multiple signatures as an additional, follow-on concern. I don't mean it's not
important; merely that it's factorable.
I also note that there are others who have raised the topic. After the current
brouhaha settles down, it might be worth considering an additional document to
deal with the topic.
>  At least not in the body of the email. Please don't consider any
> of the following as picking a fight, or even demanding a response,
> it's mostly just for completeness.
Very nice list and discussion of each item.
I suspect it would be worth having the 4871bis effort carefully consider each of
your points. On the other hand, that would guarantee that the bis effort is a
On the other hand, it could produce a substantially cleaner and simpler bit of
technology. As you note, that could dramatically reduce implementation and
testing effort (and thereby dramatically increase interoperability.)
More information about the ietf-dkim