+1
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Murray S.
Kucherawy
Sent: Tuesday, June 16, 2009 5:53 PM
To: Cullen Jennings; dcrocker(_at_)bbiw(_dot_)net
Cc: Pasi(_dot_)Eronen(_at_)nokia(_dot_)com; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)
<t>This update resolves that confusion. It defines
additional, semantic
labels for the two values, clarifies their nature and
specifies their
relationship. More specifically, it clarifies that the
identifier
intended for delivery to the assessor -- such as one that
consults a
white list -- is the value of the "d=" tag. However, this
does not
prohibit message filtering engines from using the "i=" tag,
or any
other information in the message's header, for filtering
decisions.
</t>
Look, this is clear as mud - What I am getting is that the old
document was unclear if you should use the d= or the i= and this
document clarifies it to be you should use, uh, I'm totally lost here,
I use the d= for white lists, which are a form a filtering, but I can
also use the i= for filtering.
I'm just unclear on what one is supposed to use and when. And honestly
it does not matter if I am confused in the slightest, but it does
matter if people implementing this stuff are unclear on this.
Evidently there is enough confusing about this that it is worth
writing an RFC to fix it - that I believe. However, people outside the
WG other than me seem like they too have a hard time reading this and
figuring out how this clarifies what to do. This does seem like a bit
of a problem.
Think about it in terms of an API specification.
The intent here, I believe, is to specify that "d=" is mandatory output of a
DKIM verifier module. "i=" (and everything else, frankly) is optional. Thus,
a compliant verifier implementation will give you a yes/no on the signature and
the name of the domain in "d=". There may be other stuff there, but that's
what you need for minimal compliance and interoperability. A consumer of such
a minimal specification could conceivably interchange DKIM implementations and
still keep working as before. However, there are no guarantees if such a
consumer decides to try to make use of optional stuff like "i=" or "x=" or "l="
or whatever, because some other DKIM verifier implementation might not give
that to you. But if you code for yes/no and "d=" only, then any compliant
verifier will give you what you need to interoperate.
If you as a consumer of such an API feel that you'd rather use "i=" for
particular applications or types of messages, then either create or use an
implementation that makes that value available. There's nothing wrong with
that either.
(If any of that language resolves the concern, feel free to use it.)
-MSK
_______________________________________________
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