Murray S. Kucherawy wrote: >> -----Original Message----- >>> 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. >> The current language looks fine to me. > > Some people are talking about changing the wording here. I think > it would be helpful to frame that part of the conversation. > > The text cited above as 2.3 is not new. It reached > working group consensus already because it was part of RFC5672. > Thus, its presence in RFC4871bis is already effectively approved.
And the same concerns cited then were also ignored. > Any changes to it require new consensus. My citing it isn't > introducing anything new; anyone that is proposing changes to it > has to garner consensus to make any changes stick. Murray, consistent modeling of all documents is ideal and from an mail system integration standpoint, higher welcomed by implementators, specially those with mail products in the place. But a fine line has been crossed when you talking about an open standard with hooks for future adaptations and one that begins to cater to a specific commercial business model interest with no hooks or lock out for future alternatives such as policy. The thing is you don't need it, signer domain is enough, we get it and all this does is give a black eye to DKIM. And even though, its not as big an issue than how it encourages HANDLING by REPUTATION as the expense of not encouraging handling by POLICY, which in the anal world of standards correctness, HANDLING be an open-ended concept allow for future adaptability. So if anything that term does not fit with section 2.3 to define what are the identities. Signer domain is the identity, not "Independent Trust Assessment Service" because its it different concept and layer quite frankly, and worst, it adds to the "Batteries Required" PR problem DKIM has. But if you want to be fair, and want to keep it in, in the spirit of Cooperative Competition (CooComp) use common open standards, then it only prudent to also add: "Domain Signing Practices Policy Assessment Engines" The problem that the current document is peppered with only trust ideas and not policy, which by itself breaks the spirit of isolation raw DKIM-BASE processing standard from any specific implementation ideas for handling results. I think we need to stop playing these games and just add a section in DKIM to deals with the serious dearth and ultimate need for DKIM - HANDLING. I don't see any issue with generalized suggestions for DKIM assessment technologies possible for DKIM handling, that recognizes both TRUST and POLICY methods. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html