ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Handling the errata after the consensus call

2009-03-07 02:18:57

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

<Prev in Thread] Current Thread [Next in Thread>