-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Friday, April 01, 2011 4:30 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Open issues in RFC4871bis
On 4/1/11 2:08 PM, Murray S. Kucherawy wrote:
The first, and biggest, is the removal of “i=” that Jim has proposed
separately, so please comment on that thread.
For ADSP the d= and the From domain must match, which removes the need
for i=. Nevertheless, the i= can introduce different identities that
might assist when transitioning to different IDN encodings. [...]
Doug, I reiterate: Please comment on *that* thread. That is, discuss "i=" over
there, not here.
2) The document has text related to “assessment”. Does an “independent
assessment service” fit into the DKIM model? Again, the issue is
whether or not we want to include discussion of uses that are possible
but uncommon. Is there support for this change, or support against
making the change, or does it not really matter?
It is likely the only sustainable assessment will be matching with known
good sources, which would benefit by having a means to handle aliases
and authorized paths. :^)
I have no idea whether you're expressing an opinion for or against the
suggested change here.
The text in question is this:
*2.3**. Identity*
A person, role, or organization. In the context of DKIM, examples
include the author, the author's organization, an ISP along the
handling path, an independent trust assessment service, and a mailing
list operator.
DKIM should make no claims about identities. DKIM only relates signed
portions of a message with that of a domain that publishes the public
key. Would it be right to suggest this domain _is_ an identity?
Section 2.3 is only a definition, not an expression of signature semantics.
So, again, I don't understand how you're answering the question(s) here.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html