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
