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