ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Output summary

2011-04-29 21:26:15
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Friday, April 29, 2011 6:16 PM
To: Michael Thomas
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary

What gets me is that I thought IETF bis work were suppose to help
codify existing implementations - bring it up-to-date.   That was
burned into me by Hansen and Klensin.

It is indeed an effort based, at least in part, on clarifying stuff we learned 
since the earlier version based on experience.  I think it's pretty clear 
that's what's being done.  Dropping "g=" is a prime example.

But "codifying existing implementations" sounds like you expect a bis effort to 
write into "law" the code you or others may have written.  That's not what this 
is for, especially if we got parts of it wrong.  The point is to learn what 
worked and what didn't, and what can be improved both in design and description.

If you look at your DKIM implementation and see RFC4871, RFC5451 and RFC5617 
all present, that doesn't justify the argument that RFC4871bis has to 
explicitly support all possible use combinations of the three.  That's mixing 
specification with product design, and it's a gigantic no-no. 

All implementations go beyond
what RFC4871 and RFC4871bis is not really learning from those
DKIM-years deployment experiences.  Older APIs had to be changed to
include A-R. Policy was always part of the API and never removed. Just
modified from SSP to ADSP.

Sorry, but this doesn't make any sense.  Both A-R and policy functions, plus 
reputation and anything else that wants to use what DKIM provides, operate at 
different levels than DKIM does.  A DKIM API doesn't need to know anything 
about A-R, because DKIM works just fine without A-R.  Same with policy, same 
with reputation.

An API that was based solely on RFC4871 and was never modified, augmented, or 
wrapped to support ADSP or A-R will work just fine as-is in the RFC4871bis 
world.  Whatever you're doing now, unless it's already broken by definition, 
doesn't have to change.

The sky is not falling.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html