As I wrote, I'm neutral to positive on MOST of the errata, but my memory
and Dave's differ.
On 2/2/09 8:26 AM, Dave CROCKER wrote:
1. The issue was not raised.
To be fair, the issue was raised after last call, and it was vague.
This guidance is not in dkim-base (purposefully),
but I believe that we had intended i= to provide that clarity.
On the other hand, Doug Otis discussed the use of i= as early as 8/30/05
in his email to you of that date. You could have picked it up and run
with it but you demurred. Ok. Who knew? As you wrote, it doesn't
really matter if the issue is so important that it requires a fix now.
I think perhaps it would help, Dave, if you could step through the
ramifications of your concerns. Also, I have the following additional
questions:
However the specification defines two, potentially different
identifiers that are carried in the DKIM-Signature: header field and
might be delivered to a receiving processing module that consumes
validated payload. The DKIM specification fails to clearly define
what is "payload" to be delivered to a consuming module, versus what
is internal and merely in support of achieving payload delivery.
This statement to me argues that the matter is substantial and clearly
requires WG participation. What it doesn't say is how the confusion
manifests itself. Can you please clearly do so with examples? The
reason I ask is that I would like to more clearly separate the problem
from the solution.
Also:
If the UAID is not the same as the address in the From:
header field, the mail system SHOULD take pains to ensure that the
actual UAID is clear to the reader.
If you are going to go to lengths to separate the Identity Assessor from
other parts of the system, it makes it more confusing when you continue
the old phrasing of "mail system" above. Which mail system? Who is
responsible for that? I presume you mean the signer, since the signer
is the one who inserts the UAID.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html