At 9:07 AM -0500 12/21/05, Tony Hansen wrote:
I would be happy with the text that was used in the xmpp charter:
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.
This text still keeps the bar high for unnecessary changes, was already
vetted through an existing charter, and helped us through a similar
impasse when xmpp was chartered.
Tony Hansen
tony(_at_)att(_dot_)com
I agree with Tony on the benefits of re-using this language, and it certainly
works for me.
I'd also like to thank Stephen Farrell for pointing out the overview document
as a logical place to answer the relationship to other IETF technologies
questions. The current language for that work item says:
An informational RFC providing an overview of DKIM and how it can fit into
overall messaging systems, implementation and migration considerations, and
outlining potential DKIM applications and future extensions.
I suggest adding "how it relates to other IETF message signature technologies".
Given that this document already discusses other potential DKIM applications
and future extensions, Stephen is right that the discussion fits here better
than either place I earlier suggested.
regards,
Ted Hardie
Barry Leiba wrote:
Eric Rescorla wrote:
Since experimentation resulted in significant Internet deployment
of these specifications, the DKIM working group will make every
reasonable attempt to keep changes compatible with what is
deployed, making incompatible changes only when they are necessary
for the success of the specifications.
Can someone propose an alternative to the first-quoted paragraph above,
from the proposed charter, that keeps the sense that the specifications
we're agreeing to use as a starting point be strong conflict-resolution
guides, and that they be used to steer the discussion... without making
it seem, incorrectly, that the WG is not willing to accept changes that
make sense to make?
Barry
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf