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. Thanks -- Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
