[ietf-dkim] Handling the errata after the consensus call
hsantos at santronics.com
Fri Mar 6 22:38:55 PST 2009
DKIM Chair wrote:
> 1. Include the other errata into Dave's draft, leave the whole thing as "old text
> / new text" format, and put it out as an RFC that updates 4871. There would be
> no rev of 4871, and implementors would need to use both documents. Work on
> 4871-bis from there.
> 2. Include the other errata and Dave's draft into a 4871-bis, which would
> obsolete 4871 and make sure that implementors get the right version. Nothing
> would go out as "old / new"; the merged document would be a rev of 4871. Work on
> 4871-ter from there.
Personally, I am not all familiar with procedure, but from a marketing
standpoint, I would like to suggest that if Dave's errata is going go
forward, that an abstract be updated to include an executive summary
of what is the key/fundamental changes and if possible, the effects
and repercussions. i.e. don't force people to read deep into the
errata to find out if any of this matters and/or applies to them.
> Then there's the question of where ADSP stands, and whether it can proceed as is,
> or needs to be changed in light of the "errata". Pasi may have some comments on
> this, and I know the working group will. We've been holding ADSP up for a while,
> and we need to release it and move it forward.
+1. This is our own holdup on moving forward with DKIM.
I just to make a final statement here to reiterate I think the #1
benefit is exclusive signings (where I believe the highest payoff will
be with private domains), and ADSP will offer some assistance in this
area. ADSP will allow us to provide the technical selling and
incentive, a reason to explore DKIM to our customers.
More information about the ietf-dkim