Stephen Farrell wrote:
Michael Thomas wrote:
My understanding in the chartering phase is that there was a great
deal of desire to not make backward incompatible changes unless they
were really, really needed. Ie, for things like security botches, and
the like. This is much more of an enhancement and to my mind a fairly
marginal one at that. Consider this: this will be setting the
precedent on what is acceptable for breaking backward compatibility.
You are correct that this is an enhancement and not a bug-fix.
But if the WG consensus turns out to be for it, then that's
where we end up, right?
During the chartering phase, the key concern that I -- and I
think many others -- was introducing gratuitous backward
incompatible changes from allman-01. To date, we've contemplated
two changes:
1) use of relaxed over nowsp
2) sha-256
Both security related. Both _necessary_.
I'm far from convinced that _any_ permutation of this is worth breaking
backward compatibility. None of the reasons you gave seem compelling to
me.
That's a fair position. Others may disagree, equally fairly.
However, given that we have agreed to basically move to sha256,
signers who use sha256 will be signing incompatibly with allman-01
verifiers so I don't see why this change would be significant,
following on from that change.
I don't consider sha256 a very good counterpoint: we're making
that change because we _have_ to, due to forces outside our
control. This change is in our control, however.
As I said, this would set the barrier for incompatible changes
*much* lower than before, and I worry greatly about the stability
of the spec were that to happen.
Having a way to detect which broke -- header or body -- does not
require breaking backward compatibility.
Sort-of. Adding the putative "X=" header-hash you mentioned would
also require a verifier to do more than allman-01, so detecting
which is broken would require a verifier change, although such
signatures would remain compatible with allman-01 as you point
out.
It does not break current implementations though. As Murray
and Arvel's implementations can attest. The current proposal
will break all of our implementations. Needlessly, IMO.
Mike, who is not even sure that
we really need anything along these
lines long term, which is why I never
brought up my header hash hack up as a
possible addition to -base.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html