Hector Santos wrote:
Dave CROCKER wrote:
On 4/15/2011 12:10 PM, Murray S. Kucherawy wrote:
All of that discussion belongs in the deployment document or some unwritten
specs about policy or reputation (which is all semantics), not in the base
specification (which is all syntax).
+1
It's more fun to re-fight old battles that are out of scope for the current
work, but it's not nearly as productive.
This is not fun.
It is 100% in scope. An authorized signer is a natural identity of the
DKIM consideration, implementation, deployment and a major efficacy
and durability factor.
The surreal aversion to include this identity in section 2.3 needs to
be explained based on the dearth of technical merits as an DKIM
identity. That is not have been done, and doing so would be a
productive time well spent.
The intentional neglect for excluding a valuable DKIM identity
component is not an acceptable engineering solution.
As a follow up:
If the WG problem is the the simple issue compromising two word term
"authorized signer" for section 2.3, there is still corrections to be
made.
Issue Evidence of Conflict:
1) Section 2.5 defines SDID as a responsible identity with a high
emphasis *mandatory* payload output for DKIM. However, this mandatory
identity is excluded in section 2.3.
2) Section 2.7 Identity Assessor describes functional modeling for
using the mandatory output SDID as the minimum input. However, this
mandatory identity is excluded in section 2.3.
Corrective Solution:
In section 2.3:
A person, role, or organization. In the context of DKIM, examples
include the author, the author's organization and responsible
signer identities along the handling path as described in
section 2.1.
In section 2.7:
2.7. Identity Assessor
A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID). The module is
dedicated to the assessment of the delivered identifier, such
as an independent trust assessment service.
Other DKIM (and non-DKIM) values can also be delivered to
Identity Assessor modules. However, this additional activity
is outside the scope of the DKIM signature specification.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html