Although not encouraged, non-backwards-compatible changes to the
basis specifications will be acceptable if the working group
determines that the changes are required to meet the group's
technical objectives and the group clearly documents the reasons
for making them.
I agree with Tony on the benefits of re-using this language, and it
certainly works for me.
It does not work for me. It is biased in the wrong direction. It is
entirely inappropriate to encourage the WG to produce output that is
compatible with a specification that is known to have significant flaws.
Consider also the following:
a) we already know that incompatible changes are necessary, thus
verifying software will need to be upgraded
b) as DKIM is specifically NOT intended to provide assurances of message
authenticity for more than a few days, compatibility with existing
signatures is of little consequence anyway
I suggest that the IESG replace that paragraph in the proposed DKIM
charter with the paragraph above, and that we move on from this topic
to any others that need to be dealt with.
I suggest the IESG replace the paragraph with the following:
While it is understood that the WG will use the current DKIM
specifications as a starting point, the WG is neither expected nor
constrained to specify a standard which is compatible with those
specifications. The WG should feel free to make whatever changes are
necessary to produce a specification that is robust with respect to the
requirements and flexible enough to support a diverse set of usage
scenarios.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf