Ok, but the language of the draft charter are pretty strict:
The specification will be based on the <draft-*-dkim-*.txt> draft
documents and will make only the minimal changes deemed essential
to the viability of the service.
OK lets look at this in stages.
What we want to do here is to develop a message signature specification
based on the DKIM draft. In particular:
* We do not want to address major functionality not addressed in DKIM
such as message encryption, securing the DNS etc.
* We do not want to undertake to provide a general mechanism for
publishing a protocol security policy, the only protocol we are
addressing in that respect is SMTP.
* We do not want to provide a venue in which people can propose
alternative mechanisms that are functionally equivalent to DKIM.
Nor does it appear that the ADs are likely to want us to do any of those
things since these are not likely to be productive with respect to the
goal of signing Internet email.
The language provided by David appears to meet the goals stated above
but may be overly restrictive. In particular it seems to me that we
should be looking to encourage WG participants to suggest enhancements
and extensions that improve the functionality of DKIM *BY* *BUILDING*
*ON* *THE* *EXISTING* *CORE*.
This is what happened with S/MIME, SSL, PKIX and most of the successful
IETF security working groups. The WG is started by a group that puts a
relatively self consistent and coherent package of functionality on the
table and people work off that basis.
I don't think David's wording is optimal here. In particular we should
note that we actually have deployed and running code here which the
existing DKIM drafts have generally protected. I think that we can meet
the intent of David's words most effectively by saying that the WG
should produce a specification that is backwards compatible with the
input documents as far as is practical unless an incompatible change
offers clear and significant benefits.
In other words I do not want to waste time arguing over the syntax we
should adopt in the DNS records or debating an entirely different draft
that is functionally identical but uses different tag names.
I suggest:
The specification will be based on the <draft-*-dkim-*.txt> draft
documents and changes that are incompatible with the deployed base
of systems that comply with this draft will only be taken if they
are deemed essential to the viability of the service.
That leaves the door open for people to suggest embelishments and
curlicues. This type of behavior also carries certain risks but they are
risks that are very familiar to WGs and WG chairs are already alert to
the need to channel that type of behavior into suplimentary drafts if it
might threaten the delivery schedule of the group.
Since there are going to be extensions proposed it would clearly be best
for the group to have the option of discussing them within the group
rather than have them be submitted as individual submissions or worst of
all have someone just deploy.