On 3/30/25 5:21 PM, John Levine wrote:
It appears that Michael Thomas<m...@mtcc.com> said:
I seem to recall previous discussions have suggested that the "v" tag
shouldn't have been included in the first place; if things are so
different that you need to change the version, you may as well change
the name of the header field altogether.
Seems like six of one, half dozen of the other. The version change sort
of signals that it has a backward incompatible change, but everything
else will be the same. ...
The obvious reason to have a new header is that there's a new tag that the
evaluator has to understand. You can't do that in a backward compatible way.
It doesn't "need" to understand it, any more than any new extension
"needs to be understood". Deployments are completely at liberty to
ignore any soi-disant "DKIM2" regardless of whether it's a new header or
an upgrade to DKIM. The authors can want it to be deployed all they
want, but it's not up to them.
I tried a couple of ways to kludge that in for my conditional chained
signature draft, none very satisfactory:
https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
Does this run on the assumption that DKIM isn't a trace header? I keep
asking and nobody will answer. Two different working groups, two
different bouts of silence.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
