Hi, I don't know if am repeating anything here, but from my standpoint, there are two different parts here:
1) Transparent Verification at the receiver, 2) Presentation, if any, to the user. I believe the latter is still unresolved here. But the verification part needs to be settled first regardless of the presentation methods. This is the part that needs to get resolved before we can even consider implementation. From that standpoint, the 'i=' attribute is meta information, opaque in nature and unrelated to the verification, at least that is what I am assuming was the case and continues to be the case. Our implementation plan has always been is to do policy checking first, DKIM validation second, using Failure Analysis as a key method for automated rejecting. Although the ADSP has replaced SSP, the logic was outlined in the deprecated I-D: http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html In short, I am hoping that protocol consistency can be resolved among the discussions here related to this i= meta data. -- Sincerely Hector Santos, CTO http://www.santronics.com pasi.ero...@nokia.com wrote: > <wearing AD hat> > > I think the proposed text changes would make RFC 4871 significantly > easier to understand, and less prone to multiple interpretations. > (I don't have a strong opinion about the content, though -- but > a clear spec is better than an ambiguous one.) > > However, it seems we're not just fixing simple errors in the wording, > but adding new design that was... well, somewhat underspecified in > RFC 4871, or at the very least, not well understood at the time (or > understood in different ways by different folks). > > That probably goes a bit beyond what should be changed using errata, > and I would suggest doing 4871bis instead. If there's rough consensus > about the content, I think it'd be possible to get it published as RFC > relatively quickly (say, well before the summer). > > (Nonetheless, for discussing what needs to be fixed in RFC 4871, a > draft containing only the changes, like draft-ietf-dkim-rfc4871-errata, > is probably quite useful. Merging the changes to produce a 4871bis draft > can happen also after we've reached rough consensus on them.) > > Best regards, > Pasi > >> -----Original Message----- >> From: ietf-dkim-boun...@mipassoc.org >> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of ext Dave CROCKER >> Sent: 26 January, 2009 09:24 >> To: DKIM IETF WG; DKIM IETF WG >> Subject: [ietf-dkim] draft Errata on RFC 4871 >> >> Folks, >> >> Howdy. >> >> I've just submitted an Internet Draft with text for the >> working group to >> consider. A group of us have been working on it. >> >> It clarifies and resolves the roles and relationship of the >> d= and i= tag. >> >> An html version of the I-D is at: >> >> <http://dkim.org/specs/draft-ietf-dkim-rfc4871-errata-00.html> >> >> d/ >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> NOTE WELL: This list operates according to >> http://mipassoc.org/dkim/ietf-list-rules.html >> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html