On Oct 12, 2005, at 3:01 PM, Dave Crocker wrote:
There was a great deal of contention regarding what DKIM was
attempting to achieve at the Paris BOF.
there was? there was a great deal of contention about how to run
the meeting, but serious debate about the 'purpose' of debate --
enough debate to justify your assessment -- was entirely lacking,
from my own memory of it.
The BOF ended in debates regarding what feature of DKIM can be
defended or used to justify a WG. It was not uplifting to hear
suggestions demonstrating a lack of understand regarding what DKIM
can and can not do. In addition, there was a fair amount of
reflector bandwidth dispelling misperceptions regarding what had been
implied by forgery protections. Forgery related statements of the
problem being solved are misleading and not productive.
Nor does the current charter reduce this confusion. There are
aspects within this charter that remain misleading, such as
suggesting the mechanism is to solve header forgery.
All documents can be improved. What is significant, here, is that
the previous charter went through extensive review and revision.
It therefore make sense to consider charter text in terms of
surgical revisions. You want to suggest specific text changes,
that's fine. But it cannot possibly be productive to have (yet
another) sequence of wandering through the weeds of general charter
criticism.
At a minimum, remove misleading statements regarding header forgery.
This rewording of the beginning paragraph should be less confusing
about what is being accomplished. Of course, trust should be
extended to include behavior. How about:
-----
Establishing a domain name that is accountable for a message being
offered is a problem for users of Internet mail when deciding whether
to accept a message. DKIM establishes a name that may act as a basis
for trusting the conduct and content of the message and selected
headers. The DKIM working group will produce standards-track
specifications that permit authentication of a domain name associated
with the message using public-key signatures and based upon domain
name identifiers. This specification will also verify that selected
headers and message content has not changed subsequent to the domain
name association by way of the signature.
----
_______________________________________________
ietf-dkim mailing list
http://dkim.org