Russ,
My concern was that you only talked about the backward compatibility.
In the future, please couple the backward compatibility issue with the
other dimensions discussed in the charter.
Let me see if I understand the requirement you are describing:
1. Someone makes a suggestion for a change.
2. The group discusses its benefits and leans towards adoption.
3. Someone else notes that this breaks validation from pre-IETF signers.
(further steps occurred, but your rule appears to apply to this third step)
It appears that you are asserting that any such expression of concern about
incompatibility requires repeating whatever the trade-offs are, nevermind that
the benefits have already been expressed.
It further appears that anytime someone expresses a concern for compatibility
with pre-IETF implementations, but fails to include other text that discusses
this as a collection of trade-offs, you or a chair feel compelled to treat the
concern as if it were a scope or process challenge.
Since I am not aware that any other expressions of benefit or detriment are
automatically expected to carefully list a full set of trade-offs, please
explain the assertion of this policy in this case.
For example, a statement
that a backward compatibility concern can be avoided if we do A instead
of B to meet technical objective C is completely appropriate. I did not
interpret you message in this light.
Like Stephen, you appear to have read vastly more in my text than I put there.
I never stated nor implied my own preference about the resolution of the current
topic. (For reference, I was in fact conflicted about it.) Rather, I was and
am concerned that incompatibilities be treated carefully.
Again, the DKIM charter says:
Thanks for including that, yet again. I hadn't read it carefully enough before.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html