> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Douglas Otis > Sent: Friday, April 01, 2011 4:30 PM > To: [email protected] > 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
