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?
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.
> 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.
I'd be interested in more opinions, including those in the room
yesterday, who might have changed their minds, or not...
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html