First thanks to the WG for trying to address the problem I had raised.
I had assumed nothing would be done to try and correct so I just put
abstain as clearly some people felt the document was worth publishing
but as we are trying to fix or clarify this, let me be more explicit.
My focus is mostly on what this errata means to implementations in the
field. That would be implementations of both DKIM the narrow signing
protocol and implementations that use the information DKIM provides. I
think the document should be clear on
1) what is the interoperability problem. Can someone succinctly
summarize this? When I read the document, I get that there is a
problem but it less clear what it is or why some implementation would
end up doing something that did not work with other implementations.
2) what needs to be changed in implementations to fix this? Again, can
anyone succinctly summarize this. I do not think an implementor that
did not follow the list could easily read the current draft and figure
out if there code was OK or not and what changes where needed to their
code to make it OK
More inline ....
On Jun 15, 2009, at 19:22 , Dave CROCKER wrote:
Jim Fenton wrote:
I do have a problem with the last paragraph:
<t>For signers and assessors that have been using the i= tag
for
reputation assessment a software change to using the d=
tag is intended.
</t>
and some of the text in the preceding paragraph because it attempts
to
do exactly what the WG charter says we won't, specifically:
New Proposed Text:
<t>This currently leaves signers and assessors with the
potential for
making different interpretations between the two
identifiers and may
lead to interoperability problems. A signer could intend
one to be
used for reputation, and have a non-reputation intent in
setting the
value in the other. However the verifier might choose the
wrong value
to deliver to the assessor, thereby producing an unintended
(and
inaccurate) reputation assessment.</t>
I'm not really sure what you mean by a reputation intent and non-
repuation intent or when a signer or verifier would want one or the
other.
<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.
<t>For signers and verifiers that have been using the i= tag
as the
primary value that is delivered to the assessor, a
software change to
using the d= tag is intended.
</t>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html