[ietf-dkim] Charter bashing...

[Douglas Otis]

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.
----