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