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(_dot_)Eronen(_at_)nokia(_dot_)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-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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