[ietf-dkim] Output summary

[Murray S. Kucherawy]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Hector Santos
> Sent: Friday, April 29, 2011 6:16 PM
> To: Michael Thomas
> Cc: ietf-dkim at mipassoc.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.