[ietf-dkim] DKIM tithing

[Dave CROCKER]

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 
disproportionately high.


> 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[1], 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 
worth considering.


> 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.


> [1] 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 
substantial probject.

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.)


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net